commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rahul Akolkar <rahul.akol...@gmail.com>
Subject Re: [SCXML] SCXMLSerializer and package reorganization (WAS: [scxml] a few observations, issues before release)
Date Thu, 19 Jan 2006 00:24:59 GMT
On 1/18/06, Tim OBrien <tobrien@discursive.com> wrote:
>
>
> --- Rahul Akolkar <rahul.akolkar@gmail.com> wrote:
<snip/>
> >
> >  * We need to reading in arbitrary document fragments (digester has a
> > NodeCreateRule)
> >  * 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
> >
>
> Betwixt leverages the Digester, in fact, the BeanReader is a subclass of the Digester.
 If you
> capture the mapping from SCXML to the State model objects, in .betwixt files, you are
essentially
> using the Betwixt framework as a short-hand for the digester rules.  You can handle mapping
to
> existing commons SCXML objects right now with Betwixt.
>
<snap/>

I need to spend some time reading up Betwixt then.


> I think that you shouldn't discount the important of writing, I think that it is something
that
> could come in very handy.
>
<snip/>

While I haven't completely bought into importance of writing to be *at
par* with reading, you're probably right and it definitely cannot hurt
to have well designed writing capabilities, so lets try.


> > 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.


> > 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.


> >  * The post-processing picks up the loose ends. For example, for this snippet:
> >
> >    <transition ...>
> >     <target next="foo" />
> >    </transition>
> >
> >    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 think that the post-process would also include identifying external src attributes
and invoking
> another BeanReader, recursion...
>
<snip/>

Yup, the digester currently sets up a similar recursion (as you've seen).


> >
> > 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
> > suggestions?
> >
>
> I think it would be wise to take references to "Digester" out of the class name entirely.
> SCXMLReader and SCXMLWriter?  SCXMLFactory, I'm not a big fan of naming debates ("bricks"
vs.
> "WebComponents"), but marrying this component to Digester in the class name might be
more
> confusing to the population of users who will just want to read in an SCXML document.
>
<snap/>

Makes sense, no digester in the name then. Reader/Writer sounds good too.


> Is this more branch experimentation work?
>
<snip/>

Definitely, given my lack of Betwixt-savvy (soon to change, if I may
say so optimistically ;-). Again, I'm interested in getting the
packages right in trunk before we branch any.

-Rahul

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message