There are internal services that can be overridden to handle those kinds of situations.
The goal is to create something that works amazingly well for all the more typical cases, then start going after these others. Often it will involve moving a private interface out into the public space ... but once that's done, its very hard to change the interface in the future without breaking backwards compatibility, so we're pretty conservative about pulling back the curtain until we know the interface is full and complete. On 5/30/07, David Kendall <[EMAIL PROTECTED]> wrote:
I am a Tapestry newbie getting up to speed on Tap 5. I am working on an application with extensive co-branding requirements. As I understand things, there is - by default - a tight coupling between a component class name and its template path. For example - if a component has a FQCN of... org.example.myapp.components.CClamp ...then the template has to be on the classpath as.... org/example/myapp/components/CClamp.html It would be very helpful if the mapping between the component and the template could be decoupled - this would allow me to pull in component templates that have been tweaked for a particular co-brand. For example - I might want to have a template on the class path as org/example/myapp/override/cobrand1/components/CClamp.html Is there any way to do this? Thanks in advance. David Kendall --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- Howard M. Lewis Ship TWD Consulting, Inc. Independent J2EE / Open-Source Java Consultant Creator and PMC Chair, Apache Tapestry Creator, Apache HiveMind Professional Tapestry training, mentoring, support and project work. http://howardlewisship.com
