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]
