commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim OBrien <>
Subject Re: [SCXML] SCXMLSerializer and package reorganization (WAS: [scxml] a few observations, issues before release)
Date Thu, 19 Jan 2006 15:32:46 GMT

--- Rahul Akolkar <> wrote:

> > > 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.
> > >
> <snap/>
> Umm, any comments on this new "test" package from the command-line
> testing classes? Unless you scream, I might go ahead with this. I
> sometimes feel they (Standalone/StandaloneUtils classes) might be
> muddying up their current packages.

No objections. +1

> > > 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
> > >
> >
> > Alright, I'm +1 for us attempting to capture this in a series of .betwixt files
in the model
> > package and leveraging BeanReader (which is essentially just creating Digester rules
from the
> > mapping).  I think this would make it easier to say support other attribute from
the draft as
> > needed (like delay).
> >
> <snap/>
> Didn't catch the delay comment, but Betwixt sounds good if you're all
> for it. Is it your intent to get something in there to get us started?
> That would be great.
> Does it have to be in the model package? Maybe we should have a
> separate "io" package (even child of model)? Though I don't want to
> spend too much time on the names here, seems like it really might be
> useful to separate the model itself from the read/write business, IMO.

It would help if the .betwixt files were in model package, but I do agree that any class that
with reading/writing should be in an io package.  Don't get too caught up on that couplng
just yet
until you see it.

The delay comment was a reference to an attribute (i think on transition) from the working
that SCXML doesn't yet support.  The point being that as SCXML comes to implement more and
more of
the specification, what you are really doing is just adding more properties to the model,
I think
this would be easier to capture if we didn't rely on hand-craft Digester rules and just used

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

View raw message