One other possible option I've found is to migrate the authentication app to Tapestry 4 and to make use tapestry.InfrastructureOverrides to contribute my own templateSource. I'm not sure exactly what that entails however, since I haven't had much time to work with version 4 yet.
Can anyone verify this would work, before I devote a lot of time to it? Would the default Tapestry page caching mechanism get in the way of me dynamically providing a (potentially) different template on each request? Would my overriding templateSource even be consulted on each request, or would it only be used during app initialization. If this is documented somewhere, please feel free to point me there. Thanks, Shawn Quoting Schulte Marcus <[EMAIL PROTECTED]>: > I'm having the same problem - but dodged it up to know by telling my > users > they would have to tolerate the slightly different look and feel. > When I don't get away with that anymore, I'd planned to go with your > proposal 4. I dont't think it hurts so much if you 1. put blocks that > stay > mostly the same in custom components 2. use the same Java-Page-Class > for all > "versions" of the page and 3. use mostly implicit components to keep > .page > files small. I'd hope to get away with only some duplicate code in > the .page > files this way. > Anyhow, tell me, how you solved this. > > regards, > Marcus > > > -----Original Message----- > > From: Shawn Church [mailto:[EMAIL PROTECTED] > > Sent: Thursday, September 29, 2005 5:49 PM > > To: [email protected] > > Subject: Dynamic template selection > > > > > > 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]
