You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Shawn Church <sh...@boxity.com> on 2005/09/29 17:48:31 UTC
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: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Dynamic template selection
Posted by Shawn Church <sh...@boxity.com>.
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 <ja...@dang.com>:
> 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:
> tapestry-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail:
> tapestry-user-help@jakarta.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> tapestry-user-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Dynamic template selection
Posted by Jamie Orchard-Hays <ja...@dang.com>.
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: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Dynamic template selection
Posted by Shawn Church <sh...@boxity.com>.
Mike,
Thanks for the suggestion. I initially started down that path, but I
decided on a stand-alone app for a few reasons:
First, the authentication app may be used independently. For example,
we have a number of distributors who use it to maintain their own user
groups within their organization. One or more "administrators" have
complete control over user enrollment and permissions.
Second, we had a legacy app which was not Tapestry-based, and therefore
a Tapestry component would not have served. I decided to have each
client app perform http requests to the auth "server" on each request.
The auth server (basically just responding to ExternalPage calls) would
validate the user based upon a previously-assigned ticket and then
return the xml-formatted results back to the client. If any one app
requested a logout, all other apps would immediately see it. Each
client application (whether Tapestry-based or not) redirects to the
authentication app as needed to handle login, logout, "My Account"
maintenance, etc.
Thanks,
Shawn
Quoting Michael Henderson <mh...@mac.com>:
> 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
> <sh...@boxity.com> 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:
> tapestry-user-unsubscribe@jakarta.apache.org
> >For additional commands, e-mail:
> tapestry-user-help@jakarta.apache.org
> >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> tapestry-user-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Dynamic template selection
Posted by Michael Henderson <mh...@mac.com>.
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 <sh...@boxity.com> 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: tapestry-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org