You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Rahul Akolkar <ra...@gmail.com> on 2006/01/17 06:43:05 UTC
[SCXML] SCXMLSerializer and package reorganization (WAS: [scxml] a few observations, issues before release)
On 1/14/06, Tim OBrien <to...@discursive.com> wrote:
<snip/>
> 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 of
> writing Digester rules for reading and constructing Strings for writing, use the betwixt mapping
> files as a single point of translation.
>
> The current SCXMLDigester isn't trivial by any means, but I think it would be easy to implement
> the external source rule. The current SCXMLDigester plays two roles, first it sets up the
> Digester rules and "Digests" the XML, but it also does a bit of post-processing in updateSCXML. I
> 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 in
> updateSCXML somewhere else.
>
<snap/>
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 ...
http://jakarta.apache.org/commons/sandbox/scxml/api-notes/testing-standalone.html
... 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.
Specifically-
* 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
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" />
</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'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
suggestions?
-Rahul
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [SCXML] SCXMLSerializer and package reorganization (WAS: [scxml] a few observations, issues before release)
Posted by Tim OBrien <to...@discursive.com>.
--- Rahul Akolkar <ra...@gmail.com> wrote:
> On 1/19/06, Peter Costa <pc...@yahoo.com> wrote:
> > I am new to the list
> <snip/>
> > and would like to get involved in
> > this project.
> <snap/>
>
> We're always looking for help :-)
>
>
> > 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.
> >
Understand this Working Draft from the W3C: http://www.w3.org/TR/2005/WD-scxml-20050705/
Probably the most valuable thing you could do at the moment would be to give some scrutiny to what
Rahul has come up with and understand SCXML.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [SCXML] SCXMLSerializer and package reorganization (WAS: [scxml] a few observations, issues before release)
Posted by Rahul Akolkar <ra...@gmail.com>.
On 1/19/06, Peter Costa <pc...@yahoo.com> wrote:
> I am new to the list
<snip/>
Welcome!
> and would like to get involved in
> this project.
<snap/>
We're always looking for help :-)
> 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.
>
<snip/>
One of the challenges of being an active developer, especially with
unreleased projects, is to be able to cope with lack of documentation,
and even more valuably, to be able to help improve the documentation
along the way. To that end, it is useful to just grab the code and
increase your familiarity with it, start using it and fix things that
bother you.
You can even start by answering these questions on the wiki:
http://wiki.apache.org/jakarta-commons/SCXML/SCXMLFaq
You'll find many answers in the code and the Javadocs.
You should also get familiar (if you're not already) with creating
patches, submitting them for consideration in Bugzilla, and ofcourse,
participate in discussions on the mailing lists. Some "how things
work" links that may be useful are (depending on your experience):
http://jakarta.apache.org/site/understandingopensource.html
http://wiki.apache.org/jakarta-commons/GettingInvolved
http://jakarta.apache.org/site/cvsindex.html
For SCXML resources, we basically have:
* http://wiki.apache.org/jakarta-commons/SCXML (wiki)
* http://jakarta.apache.org/commons/sandbox/scxml/ (website)
* http://svn.apache.org/viewcvs/jakarta/commons/sandbox/scxml/trunk/
(repository trunk)
* http://www.w3.org/TR/scxml/ (specification)
The first three are actively discussed on this mailing list.
-Rahul
> Peter Costa
>
<snap/>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [SCXML] SCXMLSerializer and package reorganization (WAS: [scxml] a few observations, issues before release)
Posted by Tim OBrien <to...@discursive.com>.
--- Rahul Akolkar <ra...@gmail.com> 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 deal
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 draft
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
Betwixt.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [SCXML] SCXMLSerializer and package reorganization (WAS: [scxml] a few observations, issues before release)
Posted by Peter Costa <pc...@yahoo.com>.
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 <ra...@gmail.com> wrote:
> On 1/18/06, Tim OBrien <to...@discursive.com>
> wrote:
> >
> >
> > --- Rahul Akolkar <ra...@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
Re: [SCXML] SCXMLSerializer and package reorganization (WAS: [scxml] a few observations, issues before release)
Posted by Rahul Akolkar <ra...@gmail.com>.
On 1/18/06, Tim OBrien <to...@discursive.com> wrote:
>
>
> --- Rahul Akolkar <ra...@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
Re: [SCXML] SCXMLSerializer and package reorganization (WAS: [scxml] a few observations, issues before release)
Posted by Tim OBrien <to...@discursive.com>.
--- Rahul Akolkar <ra...@gmail.com> wrote:
> On 1/14/06, Tim OBrien <to...@discursive.com> wrote:
> <snip/>
<trim/>
> <snap/>
>
> 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 ...
>
> http://jakarta.apache.org/commons/sandbox/scxml/api-notes/testing-standalone.html
>
> ... 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.
> Specifically-
>
> * 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.
I think that you shouldn't discount the important of writing, I think that it is something that
could come in very handy.
> 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
>
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).
> * 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...
> * 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
> 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.
Is this more branch experimentation work?
> -Rahul
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org