Re: T4: Putting Tapestry files inside another folder

2007-11-14 Thread Joshua Jackson
Hi Jim,

Thanks for replying. But isn't it possible to configure this just
using hivemodule.xml without having to create the classes you've
mentioned? Since I'm still new to this and do not have any idea how
would the class look like.

Thanks

On 11/13/07, Jim [EMAIL PROTECTED] wrote:
 Tapestry's HiveMind configuration provides two service points that can
 be implemented: tapestry.page.SpecificationResolverDelegate (to find
 page/component specifications), and
 tapestry.parse.TemplateSourceDelegate (to find page/component
 templates).  Implementations of ISpecificationResolverDelegate and
 ITemplateSourceDelegate, respectively, can be plugged into these
 service-points.

 So I created a drop-in JAR with:
  1.  My own implementation of ISpecificationResolverDelegate
  2.  My own implementation of ITemplateSourceDelegate
  3.  META-INF/hivemodule.xml to tell HiveMind how to plug those
 implementations into Tapestry's configuration.


 Here's my slightly-censored hivemodule.xml:

 module id=com.company...ModuleName
version=1.0.0 package=com.company...
  implementation service-id=tapestry.page.SpecificationResolverDelegate
invoke-factory
  construct class=SpecificationResolverDelegate
set-object property=context
 value=service:tapestry.globals.WebContext /
  /construct
/invoke-factory
  /implementation

  implementation service-id=tapestry.parse.TemplateSourceDelegate
invoke-factory
  construct class=com.company...TemplateSourceDelegate
set-object property=context
 value=service:tapestry.globals.WebContext /
set-object property=parser
 value=service:tapestry.parse.TemplateParser /
set-object property=resolver
 value=service:tapestry.page.ComponentSpecificationResolver /
  /construct
/invoke-factory
  /implementation
 /module


 As for the implementations, I just used modified copies of Tapestry's
 default implementations.  I inject the WebContext not just so I can
 create filepaths relative from the deployed application, but also so I
 can specify the paths for my templates/specifications via
 init-parameters in my web.xml, making the module useful in multiple web
 applications.  You can also create default specifications on the fly if
 a specification file isn't found; by requiring specific conventions, you
 can code your implementations in such a way that *.jwc and *.page files
 need not exist.  The implementations that ship with Tapestry should give
 you a pretty good idea as to how you can work in your own behavior.

 Jim



 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]




-- 
What you want today, may not exist tommorrow

Blog: http://joshuajava.wordpress.com/

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: T4: Putting Tapestry files inside another folder

2007-11-14 Thread Jim

Hi Joshua,

If you look through the configuration guide: 
http://tapestry.apache.org/tapestry4/UsersGuide/configuration.html, 
under Application extensions, you'll find the following two entries in 
the table:


org.apache.tapestry.specification-resolver-delegate
ISpecificationResolverDelegate
An object which is used to find page and component specifications that 
are not located using the default search rules. The use of this is 
open-ended, but is generally useful in very advanced scenarios where 
specifications are stored externally (perhaps in a database), or 
constructed on the fly.


org.apache.tapestry.template-source-delegate
ITemplateSourceDelegate
An object which is used to find page or component templates that are not 
located using the default search rules. The use of this is open-ended, 
but is generally useful in very advanced scenarios where templates are 
stored externally (perhaps in a database), or constructed on the fly.


While I disagree that wanting to put page specifications/templates in 
places other than the Tapestry defaults is a very advanced scenario, 
at least we do have this option available to us.  In both cases, it's 
just implementing the interfaces, so you're free to implement them 
however you want.  I did go into the Tapestry source, myself, to see how 
the default implementors were doing it.


I should be able to publish my own approach this weekend, if you're 
still having trouble and can wait a bit more.

Thanks,
Jim


Joshua Jackson wrote:

Hi Jim,

Thanks for replying. But isn't it possible to configure this just
using hivemodule.xml without having to create the classes you've
mentioned? Since I'm still new to this and do not have any idea how
would the class look like.

Thanks

On 11/13/07, Jim [EMAIL PROTECTED] wrote:
  

Tapestry's HiveMind configuration provides two service points that can
be implemented: tapestry.page.SpecificationResolverDelegate (to find
page/component specifications), and
tapestry.parse.TemplateSourceDelegate (to find page/component
templates).  Implementations of ISpecificationResolverDelegate and
ITemplateSourceDelegate, respectively, can be plugged into these
service-points.

So I created a drop-in JAR with:
 1.  My own implementation of ISpecificationResolverDelegate
 2.  My own implementation of ITemplateSourceDelegate
 3.  META-INF/hivemodule.xml to tell HiveMind how to plug those
implementations into Tapestry's configuration.


Here's my slightly-censored hivemodule.xml:

module id=com.company...ModuleName
   version=1.0.0 package=com.company...
 implementation service-id=tapestry.page.SpecificationResolverDelegate
   invoke-factory
 construct class=SpecificationResolverDelegate
   set-object property=context
value=service:tapestry.globals.WebContext /
 /construct
   /invoke-factory
 /implementation

 implementation service-id=tapestry.parse.TemplateSourceDelegate
   invoke-factory
 construct class=com.company...TemplateSourceDelegate
   set-object property=context
value=service:tapestry.globals.WebContext /
   set-object property=parser
value=service:tapestry.parse.TemplateParser /
   set-object property=resolver
value=service:tapestry.page.ComponentSpecificationResolver /
 /construct
   /invoke-factory
 /implementation
/module


As for the implementations, I just used modified copies of Tapestry's
default implementations.  I inject the WebContext not just so I can
create filepaths relative from the deployed application, but also so I
can specify the paths for my templates/specifications via
init-parameters in my web.xml, making the module useful in multiple web
applications.  You can also create default specifications on the fly if
a specification file isn't found; by requiring specific conventions, you
can code your implementations in such a way that *.jwc and *.page files
need not exist.  The implementations that ship with Tapestry should give
you a pretty good idea as to how you can work in your own behavior.

Jim



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]






  



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: T4: Putting Tapestry files inside another folder

2007-11-14 Thread Andreas Andreou
Also,
http://wiki.apache.org/tapestry/PagesAndComponentsInWEB-INF
http://wiki.apache.org/tapestry/SpeclessPagesInWEB-INF

On Nov 14, 2007 4:09 PM, Jim [EMAIL PROTECTED] wrote:
 Hi Joshua,

 If you look through the configuration guide:
 http://tapestry.apache.org/tapestry4/UsersGuide/configuration.html,
 under Application extensions, you'll find the following two entries in
 the table:

 org.apache.tapestry.specification-resolver-delegate
 ISpecificationResolverDelegate
 An object which is used to find page and component specifications that
 are not located using the default search rules. The use of this is
 open-ended, but is generally useful in very advanced scenarios where
 specifications are stored externally (perhaps in a database), or
 constructed on the fly.

 org.apache.tapestry.template-source-delegate
 ITemplateSourceDelegate
 An object which is used to find page or component templates that are not
 located using the default search rules. The use of this is open-ended,
 but is generally useful in very advanced scenarios where templates are
 stored externally (perhaps in a database), or constructed on the fly.

 While I disagree that wanting to put page specifications/templates in
 places other than the Tapestry defaults is a very advanced scenario,
 at least we do have this option available to us.  In both cases, it's
 just implementing the interfaces, so you're free to implement them
 however you want.  I did go into the Tapestry source, myself, to see how
 the default implementors were doing it.

 I should be able to publish my own approach this weekend, if you're
 still having trouble and can wait a bit more.
 Thanks,
 Jim



 Joshua Jackson wrote:
  Hi Jim,
 
  Thanks for replying. But isn't it possible to configure this just
  using hivemodule.xml without having to create the classes you've
  mentioned? Since I'm still new to this and do not have any idea how
  would the class look like.
 
  Thanks
 
  On 11/13/07, Jim [EMAIL PROTECTED] wrote:
 
  Tapestry's HiveMind configuration provides two service points that can
  be implemented: tapestry.page.SpecificationResolverDelegate (to find
  page/component specifications), and
  tapestry.parse.TemplateSourceDelegate (to find page/component
  templates).  Implementations of ISpecificationResolverDelegate and
  ITemplateSourceDelegate, respectively, can be plugged into these
  service-points.
 
  So I created a drop-in JAR with:
   1.  My own implementation of ISpecificationResolverDelegate
   2.  My own implementation of ITemplateSourceDelegate
   3.  META-INF/hivemodule.xml to tell HiveMind how to plug those
  implementations into Tapestry's configuration.
 
 
  Here's my slightly-censored hivemodule.xml:
 
  module id=com.company...ModuleName
 version=1.0.0 package=com.company...
   implementation service-id=tapestry.page.SpecificationResolverDelegate
 invoke-factory
   construct class=SpecificationResolverDelegate
 set-object property=context
  value=service:tapestry.globals.WebContext /
   /construct
 /invoke-factory
   /implementation
 
   implementation service-id=tapestry.parse.TemplateSourceDelegate
 invoke-factory
   construct class=com.company...TemplateSourceDelegate
 set-object property=context
  value=service:tapestry.globals.WebContext /
 set-object property=parser
  value=service:tapestry.parse.TemplateParser /
 set-object property=resolver
  value=service:tapestry.page.ComponentSpecificationResolver /
   /construct
 /invoke-factory
   /implementation
  /module
 
 
  As for the implementations, I just used modified copies of Tapestry's
  default implementations.  I inject the WebContext not just so I can
  create filepaths relative from the deployed application, but also so I
  can specify the paths for my templates/specifications via
  init-parameters in my web.xml, making the module useful in multiple web
  applications.  You can also create default specifications on the fly if
  a specification file isn't found; by requiring specific conventions, you
  can code your implementations in such a way that *.jwc and *.page files
  need not exist.  The implementations that ship with Tapestry should give
  you a pretty good idea as to how you can work in your own behavior.
 
  Jim
 
 
 
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 
 
 
 


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]





-- 
Andreas Andreou - [EMAIL PROTECTED] - http://blog.andyhot.gr
Tapestry / Tacos developer
Open Source / JEE Consulting

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: T4: Putting Tapestry files inside another folder

2007-11-14 Thread Joshua Jackson
I kinda get the idea now that Tapestry by default looks for page 
component specification under WEB-INF. But what I don't get is why do
we have to create a class that implements
ISpecificationResolverDelegate and then configure it again in
hivemodule.xml instead of just configuring it in hivemodule.xml.

On 11/14/07, Andreas Andreou [EMAIL PROTECTED] wrote:
 Also,
 http://wiki.apache.org/tapestry/PagesAndComponentsInWEB-INF
 http://wiki.apache.org/tapestry/SpeclessPagesInWEB-INF

-- 
What you want today, may not exist tommorrow

Blog: http://joshuajava.wordpress.com/

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: T4: Putting Tapestry files inside another folder

2007-11-12 Thread Jim

Joshua Jackson wrote:

Dear all,

By default T4 files such as *.jwc, *.page, *.html are required to be
place inside WEB-INF/.

But I find this quite messy when there are other configuration from
another framework. Is there any way I can move these files to another
folder?

Thanks in advance

  

Hi Joshua,

Tapestry's HiveMind configuration provides two service points that can 
be implemented: tapestry.page.SpecificationResolverDelegate (to find 
page/component specifications), and 
tapestry.parse.TemplateSourceDelegate (to find page/component 
templates).  Implementations of ISpecificationResolverDelegate and 
ITemplateSourceDelegate, respectively, can be plugged into these 
service-points.


So I created a drop-in JAR with:
 1.  My own implementation of ISpecificationResolverDelegate
 2.  My own implementation of ITemplateSourceDelegate
 3.  META-INF/hivemodule.xml to tell HiveMind how to plug those 
implementations into Tapestry's configuration.



Here's my slightly-censored hivemodule.xml:

module id=com.company...ModuleName
   version=1.0.0 package=com.company...
 implementation service-id=tapestry.page.SpecificationResolverDelegate
   invoke-factory
 construct class=SpecificationResolverDelegate
   set-object property=context 
value=service:tapestry.globals.WebContext /

 /construct
   /invoke-factory
 /implementation

 implementation service-id=tapestry.parse.TemplateSourceDelegate
   invoke-factory
 construct class=com.company...TemplateSourceDelegate
   set-object property=context 
value=service:tapestry.globals.WebContext /
   set-object property=parser 
value=service:tapestry.parse.TemplateParser /
   set-object property=resolver 
value=service:tapestry.page.ComponentSpecificationResolver /

 /construct
   /invoke-factory
 /implementation
/module


As for the implementations, I just used modified copies of Tapestry's 
default implementations.  I inject the WebContext not just so I can 
create filepaths relative from the deployed application, but also so I 
can specify the paths for my templates/specifications via 
init-parameters in my web.xml, making the module useful in multiple web 
applications.  You can also create default specifications on the fly if 
a specification file isn't found; by requiring specific conventions, you 
can code your implementations in such a way that *.jwc and *.page files 
need not exist.  The implementations that ship with Tapestry should give 
you a pretty good idea as to how you can work in your own behavior.


Jim



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]