>Hi all, > >I use Clay to build my pages with templates. > >I have a base page, all my actual pages are derived from the base page. >My clay-config.xml looks like this > > <component jsfid="basePage" extends="clay"> > <attributes> > <set name="clayJsfid" value="/templates/layout.html" /> > </attributes> > <symbols> > <set name="@title" value="Default Title" /> > <set name="@headercontent" value="/templates/header.html" /> > <set name="@bodycontent" value="space" /> > <set name="@footercontent" value="/templates/footer.html" /> > </symbols> > </component> > > <component jsfid="startPage" extends="basePage"> > <symbols> > <set name="@title" value="Application Home" /> > <set name="@bodycontent" value="/startBody.html" /> > </symbols> > </component> > >The "problem" is my actual page start.html it looks like this: > ><span jsfid="startPage"/> > >So the issue I'm having is that for every page I need two files >start.html >startBody.html > >The start.html page only calls the "startPage" clay component. >So I'd like to have only one file which contains my body. >Are there any possibilties to do this? > >
You will run into a conflict if the entry point of the page is has a ".html" suffix and you are using tiles like templates. In clay, we call the tiles like pages full XML views. A full XML view allows you to create a pseudo page that doesn't really map to a physical resource. I should say that it doesn't have to map to a physical resource but you can also use a clay XML file as the page entry point. I'll try to give you some more background. There are three types of clay templates. * Common XML component definitions. These definitions are defined in the clay xml schema. They can be resued in the other types of templates. The common definitions are the foundation of clay. They are similar to JSP's TLD's. They define a component, validator, listener, or converter and all of it's properties. These component definitions are declared in the web.xml using a comma delimited list. <!-- Clay Common Configuration Resources --> <context-param> <param-name> org.apache.shale.clay.COMMON_CONFIG_FILES </param-name> <param-value> /WEB-INF/clay-config.xml,classpath*:META-INF/trh-incubator-m1-SNAPSHOT-config.xml, classpath*:META-INF/tr-incubator-m1-SNAPSHOT-config.xml </param-value> </context-param> * The next type of template is a HTML(ish) markup template. This kind of template can be XHTML but the markup parse is not validating. Html templates are parsed on-demand. You don't have to preregister the templates. The suffix of the jsfid determines that it's a HTML template. The default is .html but you can change this with a web.xml context param. <!-- Clay HTML View Suffix (default .html) --> <context-param> <param-name> org.apache.shale.clay.XML_TEMPLATE_SUFFIX </param-name> <param-value>.fhtml</param-value> </context-param> Html templates use and extend common elements. This type of template can be a fragment or the entire page. If the template is the entry point to the page, it must be a physical resource meaning that it can't be a pseudo tiles like resource that doesn't exist. * The next type of template are what we call full XML views. For this type of template, the page entry point is a clay XML configuration definition. The default suffix of a full XML view is .xml but can be changed using a web.xml context param. <!-- Clay XML View Suffix (default .xml) --> <context-param> <param-name> org.apache.shale.clay.XML_TEMPLATE_SUFFIX </param-name> <param-value>.html</param-value> </context-param> Full XML views can be loaded on-demand like the HTML views. What I mean here is that you can make a single XML file for each view. Or, you can put all of the view definitions in one or more configuration files that are loaded when the application is started. These resources are declared as a web deployment descriptor context param. <!-- Clay Configuration Full XML view Resources --> <context-param> <param-name> org.apache.shale.clay.FULLXML_CONFIG_FILES </param-name> <param-value>/WEB-INF/clay-tiles-config.xml</param-value> </context-param> This option is similar to Tiles. The page entry point is not a physical resource but a metadata definition. There are separate handler for each of the three types of templates. Each of these handlers knows how to parse the templates into a common graph of config beans. Each handler has it's own cache for these config beans. The suffix of the jsfid is used to determine what type of handler should process the resource. You an think of this as a mimetype (well kind of). The handler will always look to it's own cache to resolve the component definition but anything nested under that definition can be resolved from one of the other caches. This is the reason you can't use a .html suffix for a full XML view without changing the mapping in the web.xml. The HTML and XML full view suffixes have to be mapped to the faces servlet so that these resources are first dispatched thru the faces front end controller. One other thing to be aware of is that you really need to choose one strategy as the page entry point. JSF only provides a single default view suffix. <!-- Override the default suffix for extension-mapped --> <context-param> <param-name>javax.faces.DEFAULT_SUFFIX</param-name> <param-value>.html</param-value> </context-param> Clay has a way to cheat but it requires the shale-application library. You can register a preproces comand that captures the suffix of the requesting resource. This invoked from a filter before JSF has a chance to normalize the suffix into the single default defined above. The declaration of this command in the /WEB-INF/chain-config.xml would look something like the following: <catalogs> <!-- Define preprocessing command chain for Shale to execute --> <catalog name="shale"> <chain name="preprocess"> <!-- This command is only needed for full clay html views with myfaces --> <command className="org.apache.shale.clay.faces.ClayViewHandlerCommand" /> </chain> </catalog> </catalogs> Hope that helps.. >Thanks > >Bernhard Gary
