Re: T4: Putting Tapestry files inside another folder
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
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: > >> > >> >>version="1.0.0" package="com.company..."> > >> > >> > >> > >> >> value="service:tapestry.globals.WebContext" /> > >> > >> > >> > >> > >> > >> > >> > >> >> value="service:tapestry.globals.WebContext" /> > >> >> value="service:tapestry.parse.TemplateParser" /> > >> >> value="service:tapestry.page.ComponentSpecificationResolver" /> > >> > >> > >> > >> > >> > >> > >> 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
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: 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
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: > > version="1.0.0" package="com.company..."> > > > > value="service:tapestry.globals.WebContext" /> > > > > > > > > value="service:tapestry.globals.WebContext" /> > value="service:tapestry.parse.TemplateParser" /> > value="service:tapestry.page.ComponentSpecificationResolver" /> > > > > > > > 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
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: value="service:tapestry.globals.WebContext" /> value="service:tapestry.globals.WebContext" /> value="service:tapestry.parse.TemplateParser" /> value="service:tapestry.page.ComponentSpecificationResolver" /> 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]
T4: Putting Tapestry files inside another folder
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 -- 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]