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: user@shale.apache.org
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
