Jamie, I will check it out. That would be an ideal solution, but I'm concerned it might clash with Tapestry's template cache. I will let you know how it works out.
Thanks, Shawn Quoting Jamie Orchard-Hays <[EMAIL PROTECTED]>: > I wonder if you could hack the code that returns the template to be > > configurable. You could then have properties defined in > your .application file that specify which html template to return for > > a particular app. > > Look around ITemplateSource and ITemplateSourceDelegate. > > Jamie > > On Sep 29, 2005, at 11:48 AM, Shawn Church wrote: > > > I have an common authentication application which is used by a > variety > > of client apps to provide single-sign-on and sign-off across the > > enterprise. This authentication app handles authentication of > several > > types of users (employees, customers, vendors, and end-user > consumers) > > authenticated using various methods. > > > > All of this works fine, except I now have a need to alter the look > and > > feel of the authentication UI to fit the various types of users > and/or > > calling client apps. For example, I have a new public end-user > > application which should provide a friendly and seamless-appearing > UI > > between the authentication app (login and user-profile maintenance > > operations) and the client application. This essentially boils > > down to > > a skinning requirement, but requires more than simple css > selection. > > > > Ensuring component uniqueness (i.e. - avoiding the "Template for > > component xxx contains multiple references to embedded component > yyy" > > exception) is really the root challenge here. The ways I have so > far > > attempted to handle this are: > > > > 1. Block/RenderBlock. This works fine for my Border component, > > but it > > doesn't work so well with page forms due to Tapestry requiring > unique > > components within a single page (whether those page components are > > rendered or not). > > > > 2. Littering my templates with @Conditionals around the static > html. > > This works if only simple wording or style differences are > > required, but > > if I need a different layout (ordering or position of input > > components), > > it falls down quickly. > > > > 3. Duplicate each form component in each form. This is tricky > since > > duplicate components should not populate the same page properties, > so > > this normally ends up requiring duplicate property-specifications > and > > duplicate abstract property methods. Then of course the entire > java > > page code needs to be aware of which properties it needs to worry > > > about. > > > > 4. Create truly unique (but nearly-identical) pages (.java, .page, > > > and > > .html sets) for each of the "skins". This is the cleanest solution > I > > know of, but it's still nasty. > > > > The nicest solution would be able to specify a run-time expression > for > > $template path, i.e.: > > > > <context-asset name="$template" path="selectedTemplate"/> > > > > The @Form signatures for each of the templates would need to be > > identical (so rendering/rewind would not have to be aware of the > > template selection), but I could live with that. > > > > Does anyone have any better solutions? These are all Tapestry 3 > apps > > which will be migrated to Tapestry 4 as time allows (could be a > while > > though). > > > > Thanks, > > Shawn > > > > > > > --------------------------------------------------------------------- > > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
