| Red Hat Docs > Manuals > Red Hat Web Application Framework > |
This document is under construction.
This section describes how XSL templates are selected.
Some applications require a great deal of flexibility in template selection. The CMS, for example, allows users to upload content of type "Article". These articles can be embedded in different types of pages. For instance, an article might be embedded in a page for an editor, embedded in a page for a user to read in column format, embedded in a page for a user to read in table format, or co-branded. The presentation of each article is governed by XSLT rules; the article itself is tagged <cms:article> in the XML. The XSLT rules match on the <cms:article> tag, and a different set of stylesheet rules is used in each presentation of the article. Thus, the templating system needs to be able to obtain and apply the appropriate set of XSLT rules to the same article, depending on the context in which the article is displayed. This context can be as arbitrary as the result of an SQL query.
The templating system provides two mechanisms to support dynamic template dispatch.
Red Hat Web Application Framework 5 builds a page using the following four steps:
It obtains all data for the page, both static and dynamic.
It encapsulates this data as a static XML document.
It obtains the appropriate XSLT Transformer object to apply to the XML document.
It applies the transformer, producing output (for example, HTML).
The XML document represents the complete and unchanging representation of the page. Once the XML document has been produced, the content of the page is set and does not change. Thus, any information on which XSLT transform to apply (and where the transform should be obtained) must be contained in the XML document.
You can use the templating system to handle the functional case above in one of two ways. The first approach is to use a custom presentation manager. The second approach is to rely on XML and XSLT. A custom presentation manager is recommended for situations with many possible dispatch paths and/or sophisticated application logic for dispatch. XML and XSLT provide a lighter-weight solution that can be used for simpler cases.
The presentation manager encapsulates the presentation logic that selects the appropriate set of templates to apply. Thus, instead of using the default SiteNodePresentationManager, the CMS can implement its own PresentationManager, CMSPresentationManager, that applies the appropriate template based on context. The PresentationManager interface appears as follows:
public interface PresentationManager {
/**
* Serves a page whose content is defined by the input XML
* document. Gets an appropriate XSLT Transformer object, and
* using the transformer to convert the DOM input to the final
* output.
*
* @param doc the XML document whose content is to be displayed
* to the output
* @param req the servlet request
* @param resp the servlet response
*/
public void servePage (Document doc,
HttpServletRequest req,
HttpServletResponse resp)
throws IOException, ServletException;
}
|
The CMSPresentationManager can parse the RequestContext object from the request attributes (DispatcherHelper.getRequestContext) and use the information to choose the appropriate stylesheet and apply the transformer to the XML document. If necessary, the custom presentation manager can also override the default method of stylesheet composition. Note that developers must implement three separate components, in addition to updating the PDL and DomainObjects to manage the stylesheet associations:
RequestContext: The default RequestContext interface must be extended to contain any additional information needed by the presentation manager.
PresentationManager: The default presentation manager must be replaced by an application-specific presentation manager. If the behavior of the application-specific presentation manager requires the composition of stylesheets, it is necessary to subclass SiteNodePresentationManager and override getStylesheetTransformer, servePage, and getComposedStylesheet.
Dispatcher: An application-specific dispatcher must be written to use the custom PresentationManager. One approach is to extend BebopMailDispatcher and call the setPresentationManager method.
The second approach is suitable for cases that do not require the complexity of a custom presentation manager. This approach uses the native capabilities of XML and XSLT along with the default Presentation Manager.
This approach uses two components. First, the XML document-generating component (that is, the Bebop page) is responsible for placing the appropriate semantic XML tags or attributes into the XML output document to identify the context in which the Bebop component is being rendered. In the above example, the article would appear as follows:
<?xml version="1.0" encoding="ISO-8859-1" ?>
<cms:article co-brand="village"
xmlns:cms="http://www.arsdigita.com/cms/1.0">
<cms:title>Frogs discovered on Mars</cms:title>
<cms:author>Jonly Wonly</cms:author>
<cms:body>NASA scientists reported today that they have discovered
evidence of frog life forms on Mars. They claim that the frogs are
very large.</cms:body>
</cms:article> |
The value of the co-brand and viewer attributes can come from any source in the Bebop page, for example, a database query.
The second component is the actual XSLT stylesheet, which matches the attributes above to style the output accordingly. In this case, a stylesheet would appear as follows:
<?xml version="1.0" encoding="ISO-8859-1" ?>
<xsl:stylesheet
version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:output method="html"
doctype-public="-//W3C//DTD HTML 4.0 Transitional//EN"/>
<xsl:template match="cms:article"
xmlns:cms="http://www.arsdigita.com/cms/1.0">
<html>
<head><title><xsl:value-of select="cms:title"/></title></head>
<body bgcolor="white">
<xsl:if test="@co-brand='village'">
<h3><xsl:value-of select="cms:title"/></h3>
by <xsl:value-of select="cms:author"/>
<hr />
First reported in the Backwoods Village newspaper...
</xsl:if>
<xsl:if test="@co-brand='city'">
<h1><xsl:value-of select="cms:title"/></h1>
<hr/>
First reported in the City Newspaper...
</xsl:if>
<p>
<xsl:value-of select="cms:body"/>
</p>
<hr />
</body>
</html>
</xsl:template>
</xsl:stylesheet> |
In this example, the article has a co-brand attribute that can have one of two values: city and village. The city article doesn't display the author, while the village article does. In addition, both newspapers purport to be the first in reporting the news.
These rules are stored in the filesystem or the database and are automatically associated with the Stylesheet object that is built using the standard set of templating system rules implemented in the SiteNodePresentationManager. These associations are integral with the Bebop component and are discussed in are discussed in greater detail elsewhere in the documentation.