--- Rahul Akolkar <[EMAIL PROTECTED]> wrote:
> On 1/14/06, Tim OBrien <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
