The easiest way to get started with Smooks is to:

The tutorials are the perfect base upon which to integrate Smooks into your application.

Take a look at this page.

Smooks supports DOM and SAX based processing models, but adds a more "code friendly" layer on top of them. See the user guide.

See the SmooksResourceConfiguration javadocs.

See fragment-based data processing with Smooks.

A Smooks transformation is specified as a series of "resource" configurations (typically made in an XML file). Smooks loads/looks-up/"selects" a resource at runtime through the resources configuration "selector" value. For an XML fragment (Element) transformation resource, the selector value is the XML Element name. When Smooks passes over the message and encounters each Element, it uses the Element’s name to "select" the resources to be applied to that message fragment.

A "selector" is not always an XML Element name however. An example of this would be message parser resource configurations (CSV parser, EDI parser etc), where the selector is always "org.xml.sax.driver". What happens when more than one parser configuration (under selector "org.xml.sax.driver") is targeted at a message e.g. where profiling is in use?

Check out the java-basic tutorial.

No! Smooks is a framework for performing fragment-based data processing using existing XML processing technologies (such as XSLT). Read about Why Smooks was Created.

Other technologies supported by Smooks are: raw Java, Groovy script, FreeMarker and StringTemplate templating.

First off, don’t think of Smooks as an alternative to the likes of XSLT and don’t think of the Smooks configuration as a "Transformation Configuration" in the same way as an XSL Stylesheet.

The Smooks configuration should be thought of more as a "Framework Configuration" - most frameworks have a configuration of one sort or another. It’s nothing like XSLT, which is basically a programming language in XML. It just defines how transformation/analysis resources are targeted at messages and message fragments. It doesn’t define the low level details of each individual transformation. Also note that the Smooks configuration is quite simple in terms of the number of configuration elements you need to remember - there are only a few.

See the SmooksResourceConfiguration javadocs.

Smooks can be used to simplify your XSLT in a number of ways:

Sure, XSLT supports custom extensions. The problem with XSLT Extensions is the effect they often have on your XSLT in terms of portability across processor implementations, as well as general stylesheet maintenance. Take a quick look at the mailing lists for some of the main XSL Processor implementations. You’ll see that extension portability is a recurring topic of conversation.

Smooks helps you solve the same type of problems that XSLT Extensions are designed to solve, but by keeping the extension logic separate from the XSLT. Your stylesheets should always be vanilla XSLT, without any reference to extension code. See the xslt-groovy tutorial. It uses a Groovy Smooks resource ("extension") to pre-process a date field into XML nodes that are more consumable by XSLT, removing the convoluted date field processing logic from the XSLT, keeping the stylesheet nice and simple.

We carried out some profiling in order to get an answer to this very question. The scenario we used was purposely geared in favor of XSLT. The message being processed was very flat (not hierarchical) and was not normalized and the XSLT we chose to apply was very simple. This type of scenario is especially suited to Stream/SAX based XSL processing.

What this profiling demonstrated was that in this scenario (worse case scenario) a 5% - 15% overhead is encored when comparing Smooks based application of XSLT to direct DOM based XSLT processing. However, when comparing DOM based application of XSLT (direct or via Smooks) to direct Stream/SAX based XSLT processing, we see that Stream/SAX based processing kicks ass in this type of scenario. The fact that Stream/DOM based processing can (given the right conditions) outperform DOM based processing is a long known fact.

This approach to profiling gives users of Smooks a "worse case scenario" idea of how Smooks performs when applying XSL Transforms. What users of Smooks need to remember is that Stream/SAX based processing is not well suited to all types of transforms. As well as that, Smooks offers many other features that help simplify otherwise complex transforms, while at the same time maintaining stylesheet portability across XSL Processors. We’re also very keen to add Stream and SAX based processing to Smooks.

For more on the profiling we carried out, see blog.

NOTE: Smooks v1.0 supports a SAX based processing model. More information on this to follow, or mail the User mailing list.

Absolutely! This is a classic Smooks usecase. See the xslt-groovy tutorial. It uses a Groovy Smooks resource ("extension") to pre-process a date field into XML nodes that are more consumable by XSLT, removing the convoluted date field processing logic from the XSLT, keeping the stylesheet nice and simple. The XSLT is then applied to the "#document" (root) node.

Smooks Core does support a SAX based processing model. Not all components have been updated to leverage the SAX processing model, but will be in time to come.

That said, we feel that people should remember that it’s not as simple as "Stream/SAX based processing is faster than DOM based processing". Stream/SAX is not suited to all types of transforms. For normalized messages, the performance of Stream/SAX based processing can often suffer a lot more than an equivalent DOM based transform. Counteracting this for Stream/SAX can result in more complex and unmaintainable transformations.

Absolutely! Smooks allows you configure a SAX parser on a per transform basis (based on a message profile if necessary). As long as a message is hierarchical in nature, SAX events can be generated for that message, allowing it to be consumed by Smooks. See the edi-to-xml and csv-to-xml tutorials.

The Javabeans Cartridge is not intended as a straight alternative to existing XML Binding frameworks such as those listed above. If your only requirement is that of binding XML to and from Java Objects, then you should probably go with one of the these other frameworks.

The Smooks Java binding functionality can be a very useful alternative:

We’re sure there are other use cases where Java binding using Smooks makes sense, but basically what we’re saying is that if all you are interested in is straightforward marshalling and unmarshalling between Java and XML, then JAXB/XStream etc is probably a more straightforward option, as long as your use case fits inside the parameters set down by these frameworks. If your use case cannot be solved using JAXB (etc) without major headaches (which can often be the case), then Smooks can be an option for you!

Specify the selector as "#document".

Specify the selector as "*".

They remain in the resulting document, untouched. This is unlike a templating type system (e.g. XSLT) where this would result in these fragments being omitted from the resulting document.

You can. They will be sorted an applied by Smooks in order of their configuration specificity. See the SmooksResourceConfigurationSortComparator.

Smooks supports a number of technologies and can easily be extended to support more. These technologies are bundled in what we call "Cartridges". A single cartridge may support more than one type of processing technology.

See the current list of Smooks cartridges and the technologies they add support for.

In most of the Smooks documentation we talk about Smooks in the context of data transformation. However, the core of Smooks (smooks-core) knows nothing about data transformation and so does nothing specific in this area. It’s basically an engine for applying "visitor" logic to data "fragments". This logic can be data transformation logic, or it can be logic for processing/analyzing data in any way you require.

So, the answer to this question is - "whatever type of processing you require". Just write the visitor implementation(s) and get Smooks to apply the logic on the target fragments. Visitor implementations can interact with each other via the ExecutionContext.

Absolutely!

Sure. To add support for another transformation or processing technology, you need to implement a ContentHandlerFactory for that technology. As examples, see the following ContentHandlerFactory implementations:

Registering the ContentHandlerFactory is just a matter of adding a file named "content-handlers.inf" to the META-INF folder of factory’s jar file and listing the implementation class(s) there in (one per line).