commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rahul Akolkar <>
Subject [SCXML] SCXMLSerializer and package reorganization (WAS: [scxml] a few observations, issues before release)
Date Tue, 17 Jan 2006 05:43:05 GMT
On 1/14/06, Tim OBrien <> wrote:
> 1. SCXMLSerializer
> Right now the code to serialize an SCXML object is a Visitor pattern that constructs
XML using a
> series of StringBuffers.  The code to read this XML document alrady uses a straightforward
set of
> Digester rules and the project already depends on commons-digester.
> *Alternative: Add a dependency to commons-betwixt, map the model package to XML.  Instead
> writing Digester rules for reading and constructing Strings for writing, use the betwixt
> files as a single point of translation.
> The current SCXMLDigester isn't trivial by any means, but I think it would be easy to
> the external source rule.  The current SCXMLDigester plays two roles, first it sets up
> Digester rules and "Digests" the XML, but it also does a bit of post-processing in updateSCXML.
> think the component would be well served to separate everything that has to do with serialization
> to/from XML into a separate package and to move some of this postProcess that happens
> updateSCXML somewhere else.

The reasons the SCXMLserializer exists are somewhat historic, though
it has utility from a testing/trying out POV. As the Javadoc for the
class states:

<quote>Used primarily for testing, debugging and visual verification.</quote>

It is easier to visualize the object model by just dumping it to
System.out and the Standalone classes ...

... serve as simple tools to just "try things out" at the
command-line, and are the ones that use the SCXMLSerializer.

The SCXMLSerializer does *not* serve any purpose as far as the SCXML
"engine" / SCXMLExecutor is concerned, since state charts model
behavior and the SCXML documents themselves can be considered as
immutable, and there is never any need to serialize them or write them
out (other than reasons specified in Javadocs).

I have never done any appreciable amount of betwixt, but I have used
digester. That is probably one of the most prominent reasons why SCXML
uses digester. The other being I consider this to be primarily a
directional XML --> Java object model mapping, where the other
direction is not as significant. I'm willing to spend some time in the
"research" if you're confident that betwixt is a good candidate here.

 * We need to reading in arbitrary document fragments (digester has a
 * Reading and splicing in external documents refered to via "src"
attributes (you've already answered this above)
 * Mapping to the existing Commons SCXML object model (the
o.a.c.scxml.model package)
 * IMO, we're not really interested in "writing" as much

Having said that, teasing apart the packages is a good idea. IMO, we
should introduce two new packages with this reorganization:

 (i)  o.a.c.scxml.digester - For the SCXMLDigester and its static
inner classes (pulling them out so they exist on their own)
 (ii) o.a.c.scxml.test - For the Standalone classes, StandaloneUtils
and SCXMLSerializer. This clarifies the intent of the serializer and
command-line tools much better, IMO.

How does that sound?

I'm not sure if you asked this question ;-) ... but the SCXMLDigester
does two "step" processing because:

 * As the SAX parser is throwing element start, end notifications etc.
the Digester creates the object model the best it can

 * The post-processing picks up the loose ends. For example, for this snippet:

   <transition ...>
    <target next="foo" />

   the transition target (state/history/parallel) with id "foo" may
appear later in the stream of parsing, and thus, can be only linked
into the transitions "graph" in a post-processing stage.

 * I've seen similar Digester usages not do the post-processing and
throw IllegalArgumentException's at run-time if target is not found,
but since we have all the information we need immediately after
parsing the document to verify those bits, I'm of the opinion that the
transitions graph should be verified right then and there.

I'm inclined to leave this bit in the o.a.c.scxml.digester package,
maybe we can call it something other than "digester" if you have


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message