commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Costa <pcost...@yahoo.com>
Subject Re: [SCXML] SCXMLSerializer and package reorganization (WAS: [scxml] a few observations, issues before release)
Date Thu, 19 Jan 2006 05:24:25 GMT
I am new to the list and would like to get involved in
this project.  I was wondering if you could tell me
where to get more information SCXML other than the
website.  Are there any other docs out there?  I would
like to know what you want me to do to get started on
this project.

Peter Costa

--- Rahul Akolkar <rahul.akolkar@gmail.com> wrote:

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


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

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