Table of Contents
Figure 2.1, “High Level View of the system” shows the two main parts of the Pustefix system. On the left you can see the java framework. A request coming from the browser enters the business logic. After the processing has finished, the business logic delivers the result as a (in memory) DOM tree. To get a more detailed overview of the business logic, take a look at Chapter 5, Important Concepts.
The stylesheet that's responsible to render the UI to displays the result data is requested from the XML/XSLT generator. It uses the DOM tree as input to create the HTML output that is displayed on the browser.
The stylesheet generator makes heavy use of caching to ensure that transformations are never made twice unless the result is out of date. Normally all generated stylesheets are cached in memory (and on disc). If you don't have enough memory to hold your site in RAM, you can specify other cache objects. E.g. we supply a LRU cache that can be configured to hold only the last N generated objects in memory.
Figure 2.2, “The Pustefix backend system” shows, how the different interfaces and classes in Pustefix are connected (not including web services and direct output support).
Figure 2.2. The Pustefix backend system
The Pustefix application runs within a Spring ApplicationContext
that is created by the DispatcherServlet. The servlet dispatches
all requests to HttpRequestHandlers that are managed as
beans in the application context. PustefixContextXMLHttpRequestHandler
handles the requests to Pustefix pages and takes care of session, cookie and SSL management.
The actual request processing (workflow handling, dispatching to the right
State) is performed by Context
(or more precisely ContextImpl).
The XML/XSLT System of Pustefix is responsible for generating the final stylesheet that represents the static content of a page. This stylesheet is then used together with the DOM tree that holds the result of the request (as given by the business logic) to produce the final HTML output.
Figure 2.3, “Recursive XSL transformations” shows the typical transformations and files that are
involved in producing the final stylesheet BazPage.xsl.
Note that we only discuss the common case here, arbitrary complex and deep transformation trees are in fact possible.
The red boxes are supplied by the framework, you don't need to create them yourself and as an
application programmer, you can't change them. Currently this is only the case for
core/xsl/master.xsl, core/xsl/metatags.xsl,
core/xsl/customizemaster.xsl and other stylesheets that make up the core
environment (these are not shown as they are included into master.xsl and
metatags.xsl via xsl:include transparently for the user).
The green boxes are the result of XSL transformations.
The blue boxes represent files that you need to create yourself. The [PROJECT]/xsl/skin.xsl and
[PROJECT]/xsl/metatags.xsl files are special, as they are not a target (see below) but just another
XSLT stylesheet that can be included via xsl:include into master.xsl and metatags.xsl resp.
[PROJECT]/xsl/skin.xsl contains the project specific templates that should apply on the last
transformation stage, while [PROJECT]/xsl/metatags.xsl contains the project specific templates that
apply only on the first stage.
There are projects that don't use a [PROJECT]/xsl/skin.xsl stylesheet at all or include even more
stylesheets. Making master.xsl aware of the presence of the [PROJECT]/xsl/skin.xsl stylesheet is
part of the transformation from core/xsl/master.xsl + core/xsl/customizemaster.xsl --> master.xsl
It'a also posible that a project doesn't use a [PROJECT]/xsl/metatags.xsl stylesheet or includes
more stylesheets: Similar to master.xsl it's the responsibility of the transformation from
core/xsl/metatags.xsl + core/xsl/customizemaster.xsl --> metatags.xsl to customize the resulting
metatags.xsl to include the stylesheets.
The [PROJECT]/xml/FooBase.xml file defines the structure of the "BazPage" page (e.g. frames, the outer
table structure if you do the layout with tables or divs and the like). You define one of these
structural xml files for every layout you want to use in your project (the number of structural xml
files is typically quite small, as many pages share the same layout).
The blue discs blue discs represent include parts. These are little snippets of XML code that make up the actual content of the page. As can be seen from the diagram, they can include each other, as long as there is no cyclic inclusion (so no include part can include itself either directly or indirectly). Include parts have a name and are organized into so called include documents. These can hold an arbitrary number of parts.
A target is everything that is the result of a XSLT transformation as seen in Figure 2.3, “Recursive XSL transformations”. It is also obvious that a target can be used to create new targets. For the sake of completeness, the initial XML or XSL files that are used in transformations are called targets, too.
The Pustefix system knows different types of targets:
Leaf targets are targets that are not the result of a XSL transformation, but are read directly from files. You only edit leaf targets, never virtual targets. The distinction between XML/XSL is made depending on the purpose the target serves. An XML target is read into the system without doing any special processing, while an XSL target is compiled into a templates object that is able to transform XML input.
Examples for leaf targets in Figure 2.3, “Recursive XSL transformations” are
FooBase.xml,core/xsl/metatags.xslandcore/xsl/master.xsl.Virtual targets are the result of a XSL transformation. They don't exist as files (in fact they do, but only to cache the result on the harddisk. These cache files must never be edited by hand). The difference between the XML/XSL type is the same as with the leaf targets.
Examples for leaf targets in Figure 2.3, “Recursive XSL transformations” are
BazPage.xml, andBazPage.xsl.