>After playing with it some more, I figured out the answer to my question. :-)
>
>The trick was to use the "clay" component (or a component derived from "clay")
>and pass the configurable parts to the "clayJsfid" attribute (instead of
>trying
>to pass them as part of the "jsfid" attribute directly), like so:
>
I'll try to explain the difference between the jsfid and the clayJsfid. The
clayJsfid attribute is only valid within a clay markup template. When a
template is parsed, it is loaded into a DOM like structure. Then the DOM is
processed looking for markup nodes that have a jsfid attribute. The jsfid
attribute binds the markup node to a backing component definition. So, the
parser needs to map the markup node to a clay component by jsfid. In a JSP
tag, we know that the backing component is a clay component by the use of the
JSP tag. The jsfid is assumed to be the root of the subtree under the clay
component. Used within a markup template, the clayJsfid defines the root of the
subtree but the jsfid is needed to identify that the stand-in is a clay
component.
>
>In my JSP:
>
><f:loadBundle basename="runtime" var="runtime" />
><c:clay
> id="testPage"
> jsfid="templateTestPage" >
> <c:symbol name="pageTitle" value="Test of template" />
> <c:symbol name="templatesPrefix" value="#{runtime.templatesPrefix}" />
> <c:symbol name="themeName" value="#{runtime.themeName}" />
></c:clay>
>
>
>In my clay-config.xml:
>
><component jsfid="basePage" extends="clay">
> <attributes>
> <set name="clayJsfid"
>value="@templatesPrefix/@themeName/html.html" />
> </attributes>
></component>
>
><component jsfid="templateTestPage" extends="basePage">
> <symbols>
> <set name="bodyTemplate"
>value="@templatesPrefix/@themeName/bodyTemplate.html" />
> </symbols>
></component>
>
>In this case, I'm using a message bundle named runtime.properties to pass in
>the
>theme name, but presumably, one could use a managed bean in the same way to
>obtain the theme name from user preferences.
>
That sounds like a good use. The symbols are evaluated before the property
values are passed to the component. The symbols are similar to Tiles but they
are pushed to the inner most definition where tiles symbols are not scoped the
same way (only one level).
That's one of the big reuse problems that I have with JSF using JSP. A view
fragment is bound to a managed bean using EL. Because of this, you are limited
to the context that the included view fragment can be used.
Using Clay symbols allows you to create a dictionary of reusable view
compositions.
>
>
>Rich Eggert
>Member of Technical Staff
>Proteus Technologies, LLC
>http://www.proteus-technologies.com
Gary
> -----Original Message-----
> From: Richard Eggert [mailto:[EMAIL PROTECTED]
> Sent: Sat 2/17/2007 3:53 PM
> To: [email protected]
> Subject: Dynamically-selectable HTML templates
>
> In an application I'm working on, I'm trying to implement a mechanism by
> which
> the exact HTML template file that is used for a given page is dependent upon
> a
> configurable (at a minimum, by the person deploying the application, but
> ideally, in the profile of each user) parameter such that although the actual
> information displayed by a given page remains the same, the layout and
> formatting of the page may vary according to the site "theme" selected by the
> site owner and/or user preferences. After doing some experimenting, I
> discovered that expressions are not allowed in the jsfid attribute of the
> "clay"
> JSP tag. Is there some other way of implementing this? Is what I'm trying to
> do even feasible with Clay?
>
>
> Rich Eggert
> Member of Technical Staff
> Proteus Technologies, LLC
> http://www.proteus-technologies.com
>
>
>
