Just another thought, create tapestry components for each of the authentication pieces that need to change and then return them as strings of raw html from the component and just change the HTML on the fly.
-----Original Message----- From: Schulte Marcus [mailto:[EMAIL PROTECTED] Sent: Fri 9/30/2005 12:21 AM To: 'Tapestry users' Subject: RE: Dynamic template selection 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]
