4Suite allows you to execute XSLT scripts dynamically in order to produce Web content. This can take the form:
This might not be suitable for everone, and it prevents one from taking advantage of browser caching, so 4Suite also provides several other ways of specifying such XSLT scripting, all by adding directives to the server configuration file for the HTTP server in question.
Server rules
One approach is to define server rules, such as the following:
<Rule pattern="/eggs/" xslt-transform="monty.xslt"/>
Which intercepts requests for "/eggs/" behind the scenes, applies "monty.xslt" to it (this XSLT resource is resolved relative to the "/eggs/", the source document. The result is returned the result to the user agent.
In this case, the source "document" is a container. Remember that containers in the repository can be viewed as XML documents, and thus are perfectly fine source files for XSLT scripts. This approach is most commonly used in cases where the XSLT script does not actualy get any data from the source file, but rather from other sources, such as query of the RDF model.
You can also use regular expression pattern matching in server rules.
<Rule pattern="/eggs/*.xml" xslt-transform="monty.xslt"/>
Would handle requests for any XML file in the "/eggs/" container by applying "monty.xslt" and returning the result to the user agent.
And ReST-like patterns can be emulated because named groups from the regx patterns become top-level params for the XSLT script. For instance
<Rule pattern="/services/get-quote/(?P<symbol>[A-Z]+)/?"
xslt-source="/services/get-quote/"
xslt-transform="get-stock-quote.xslt"/>
Would translate a request for
Into an invocation of the script get-stock-quote.xslt against the source of the container /services/get-quote/ with the value "MSFT" passed in as the XSLT top-level parameter value for symbol.
You can use match groups from the regular expression in pattern in xslt-source and xslt-transform. In the form \N, where N is the ordinal of the match group. For example:
<Rule pattern="/services/get-stock-info/(symbol)/"
xslt-source="/services/stock-info/\1.xml"
xslt-transform="view-stock-info.xslt"/>
Would translate a request for
Into an invocation of the script view-stock-info.xslt against /services/stock-info/MSFT.xml.
Default stylesheet setting
Another approach is to establish a default XSLT script to be applied when various sorts of resources. For example, the directive
<DefaultXslt type='#xmldocument'>/stylesheet.xslt</DefaultXslt>
Would translate a simple request for any repository resource of type xmldocument to a request to apply the XSLT script /stylesheet.xslt against the requested document.
Server rules allow you to control request handling by paterns in the request string itself. DefaultXslt allows you handle request by resource type.
Chaining stylesheets
4Suite repository features available from XSLT mean that one could easily mix the processing of the content (model) with shaping of the presentation (view). This is bad practice, so a recommended design is to use 2 or more XSLT scripts, separating model from view considerations. This is possible using chained transforms. There are two ways to chain transforms in 4Suite. One is by using server rules. If you have a rule such as
<Rule pattern="/services/get-quote/(?P<symbol>[A-Z]+)/?"
xslt-source="/services/get-quote/"
chain-multiple-transforms="yes"
xslt-transform="stock-quote-model.xslt stock-quote-view.xslt"/>
Then stock-quote-model.xslt would be applied to /services/get-quote/, and then the output from tat transform (must be well-formed XML) will be used as a source document ransformed by the stock-quote-view.xslt script. The result of this second transform would be the final output returned to the usir agent.
If you specify multiple transforms and chain-multiple-transforms="no", then the transforms are all processed in one step, as if the first specified XSLT importend the second, which imported the third, and so forth.
Using this system means that you have to know the sequence of transforms when the server is configured. You can also comute stylesheet chaining on the fly bu using the <f:chain-to href="next.xslt"/> extension element in any given XSLT script.
More information
For some more discussion, see the following threads: