Hi, How about giving the authentication app a SOAP or XMLRPC interface? Write components to interact via this interface with the authentication app. If the components are styled via CSS then you can just modify the styles in each app to accomodate the look and feel requirements.
Mike On Thursday, September 29, 2005, at 08:49AM, Shawn Church <[EMAIL PROTECTED]> 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]
