Smooks provides two main Templating options:
What Smooks adds here is the ability to use these Templating technologies within the context of a Smooks filtering process. This means that these technologies:
- Can be applied to a source message on a per fragment basis Vs the whole message i.e. "Fragment Based Transforms". This is useful in situations where (for example) you only wish to insert a piece of data into a message at a specific point (e.g. add headers to a SOAP message), but you don't wish to interfere with the rest of the message stream. In this case you can "target" (apply) the template to the fragment of interest.
- Can take advantage of other Smooks technologies (Cartridges) such as the Javabean Cartridge. In this scenario, you can use the Javabean Cartridge to decode and bind data from the message into the Smooks bean context and then use (reference) that decoded data from inside your FreeMarker template (Smooks makes this data available to FreeMarker).
- Can be used to process huge message streams (GBs), while at the same time maintain a relatively simple processing model, with a low memory footprint. See Mixing DOM and SAX Models with Smooks.
- Can be used for generating "Split Message Fragments" that can then be routed (using Smooks Routing components) to physical endpoints (File, JMS), or logical endpoints on an ESB (a "Service").
Smooks can also be extended (and will) to add support other templating technologies.
FreeMarker is a very powerful Templating Engine. Smooks allows FreeMarker to be used as a means of generating text based content that can then be inserted into a message stream (aka a "Fragment Transform"), or used as a "Split Message Fragment" for routing to another process (see above).
Configuring FreeMarker templates in Smooks is done through the http://www.milyn.org/xsd/smooks/freemarker-1.1.xsd configuration namespace. Just configure this XSD into your IDE and you're in business!
Example - Inline Template:
Example - External Template Reference:
Smooks allows you to perform a number of operations with the Templating result. This is controlled by the <use> element, which is added to the <ftl:freemarker> configuration.
Example - Inlining the Templating Result:
Inlining allows you to inline the templating result into the Smooks.filter Result object. A number of directives are supported:
- addto: Add the templating result to the targeted element.
- replace (default): Use the templating result to replace the targeted element. This is the default behavior for the <ftl:freemarker> configuration when the <use> element is not configured.
- insertbefore: Add the templating result before to the targeted element.
- insertafter: Add the templating result after to the targeted element.
Using <ftl:bindTo>, you can bind the Templating result to the Smooks bean context. The templating result can then be accessed by other Smooks components, such as the routing components. This can be especially useful for splitting huge messages into smaller (more consumable) messages that can then be routed to another process for handling.
Example - Binding the Templating Result to the Smooks bean context:
(See full example in the split-transform-route-jms tutorial)
Using <ftl:outputTo>, you can direct Smooks to write the templating result directly to an OutputStreamResource. This is another useful mechanism for splitting huge messages into smaller (more consumable) messages that can then be processed individually.
Example - Writing the Template Result to an OutputStreamSource:
(See full example in the split-transform-route-file tutorial)
FreeMarker Transforms using NodeModels
The easiest way to construct message transforms in FreeMarker is to use FreeMarker's NodeModel facility. This is where FreeMarker uses a W3C DOM as the Templating model, referencing the DOM nodes directly from inside the FreeMarker template.
Smooks adds two additional capabilities here:
- The ability to perform this on a fragment basis i.e. you don't have to use the full message as the DOM model, just the targeted fragment.
- The ability to use NodeModel in a streaming filter process i.e. Mixing DOM and SAX Models with Smooks.
- The ability to use it on non XML messages (CSV, EDI etc).
To use this facility in Smooks, you need to define an additional resource the defines/declares the NodeModels to be captured (created in the case of SAX streaming):
(See full example in the xml-to-xml tutorial)
FreeMarker and the Javabean Cartridge
FreeMarker NodeModel is very powerful and easy to use. The tradeoff is obviously that of performance. Constructing W3C DOMs is not cheap. It also may be the case that the required data has already been extracted and populated into a Java Object model anyway e.g. where the data also needs to be routed to a a JMS endpoint as Java Objects.
In situations where using the NodeModel is not practical, Smooks allows you to use the Javabean Cartridge to populate a proper Java Object Model (or a Virtual Model). This model can then be used in the FreeMarker Templating process. See the docs on the Javabean Cartridge for more details.
Example (using a Virtual Model):
(See full example in the split-transform-route-file tutorial)
Configuring XSL templates in Smooks is almost identical to that of configuring FreeMarker templates (See above). It is done through the http://www.milyn.org/xsd/smooks/xsl-1.1.xsd configuration namespace. Just configure this XSD into your IDE and you're in business!
As with FreeMarker, external templates can be configured via URI reference in the <xsl:template> element.
As already stated, configuring XSL templates in Smooks is almost identical to that of configuring FreeMarker templates (See above). For this reason, please consult the FreeMarker configuration docs. Translating to XSL equivalents is simply a matter of changing the configuration namepace. Please read the following sections however.
Points to Note Regarding XSL Support
- XSL Templating is only supported through the DOM Filter. It is not supported through the SAX Filter. This can (depending on the XSL being applied) result in lower performance when compared to SAX based application of XSL.
- Smooks applies XSLs on a message fragment basis (i.e. DOM Element Nodes) Vs to the whole document (i.e. DOM Document Node). This can be very useful for fragmenting/modularizing your XSLs, but don't assume that an XSL written and working standalone (externally to Smooks and on the whole document) will automatically work through Smooks without modification. For this reason, Smooks does handle XSLs targeted at the document root node differently in that it applies the XSL to the DOM Document Node (Vs the root DOM Element). The basic point here is that if you already have XSLs and are porting them to Smooks, you may need to make some tweaks to the Stylesheet.
- XSLs typically contain a template matched to the root element. Because Smooks applies XSLs on a fragment basis, matching against the "root element" is no longer valid. You need to make sure the Stylesheet contains a template that matches against the context node (i.e. the targeted fragment).
My XSLT Works Outside Smooks, but not Inside?
This can happen and is most likely going to be a a result of one of the following:
- The Fragment based Processing Model: Your Stylesheet contains a template that's using an absolute path reference to the document root node. This will cause issues in the Smooks Fragment based Processing Model because the element being targeted by Smooks is not the document root node. Your XSLT needs to contain a template that matches against the context node being targeted by Smooks. See the following example.
- SAX Vs DOM Processing: You are not comparing like with like. Smooks currently only supports a DOM based processing for XSL. In order to do an accurate comparison, you need to use a DOMSource (namespace aware) when executing the XSLT outside Smooks. It has been noticed that a given XSL Processor does not always produce the same output when applying a given XSLT using SAX or DOM.