XML/XSL View engine

Inspired by the Java framework Pustefix this view engine creates the view by applying XSL stylesheets on a XML tree created by the application.

Basic Configuration

To use the XML/XSL view engine you need to configure the appropriate processor in the processor configuration. The processor class for this is net::stubbles::websites::xml::stubXMLProcessor. For information on how to configure the processor configuration see Controller, Processors and Processor resolvers.

Additionally you need to configure the net::stubbles::websites::xml::stubXMLPostInterceptor as a post interceptor. See Intercepting the processing of requests on how to achieve this. The post processor takes care of applying the XSL style sheet to the XML result document created within the processor.

How the XML/XSL view engine works

The engine creates the view in two steps:

1. the processor handles the incoming request and creates a XML document that contains all required data to answer the request properly.
2. the post interceptor takes this XML document and applies a XSL stylesheet on it which results in the HTML that gets delivered back to the browser.

To make this clear we will take a look at the processing of a specific request. Let's assume that a page named "foo" is requested by the browser.

1. work of processor detailed

When the request comes to the XML processor, it first checks if such a page exists. This is done by checking if in the pages path (which can be configured in config/php/config.php) a file named foo.xml exists in the subdirectory conf. If this is not the case it falls back to processing the request as if the page index was requested.

Within this XML file the page is configured which means it has a list of all classes that should be executed on this request. (Simplified, more details can be found in the documentation about the page configuration.) The processor now executes the process() method of all these classes, and writes the return value of this method into a XML document using the XML serializer. Beside this some values will be serialized into the XML document by default, for instance some informations about the session and the request itself. The created XML document is written into the response object.

2. work of post interceptor detailed

Now, if the post interceptor would not be configured, this XML document would be returned to the browser, but that is not what we want to achieve because we want to return a HTML document. When the XML post interceptor is called, it creates a style sheet dynamically by applying the master.xsl stylesheet to the skin stylesheet which resides in a file default.xml in the skin subdirectory of the page path, which itself includes a file named main_foo.xml in the txt subdirectory of the page path. For every configured page in the conf directory a matching style sheet file should exist in the txt directory. Finally the generated XSL stylesheet gets applied to the XML document taken out of the response, and the result of this transformation replaces the contents of the response. These steps and how they can be influenced by your application are explained in detail in the stylesheets section.