Return-Path: Delivered-To: apmail-jakarta-commons-dev-archive@www.apache.org Received: (qmail 34139 invoked from network); 19 Jan 2006 15:33:12 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 19 Jan 2006 15:33:12 -0000 Received: (qmail 81332 invoked by uid 500); 19 Jan 2006 15:33:09 -0000 Delivered-To: apmail-jakarta-commons-dev-archive@jakarta.apache.org Received: (qmail 81254 invoked by uid 500); 19 Jan 2006 15:33:09 -0000 Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Help: List-Post: List-Id: "Jakarta Commons Developers List" Reply-To: "Jakarta Commons Developers List" Delivered-To: mailing list commons-dev@jakarta.apache.org Received: (qmail 81238 invoked by uid 99); 19 Jan 2006 15:33:09 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 19 Jan 2006 07:33:09 -0800 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: neutral (asf.osuosl.org: local policy) Received: from [68.142.201.33] (HELO web402.biz.mail.mud.yahoo.com) (68.142.201.33) by apache.org (qpsmtpd/0.29) with SMTP; Thu, 19 Jan 2006 07:33:08 -0800 Received: (qmail 16057 invoked by uid 60001); 19 Jan 2006 15:32:46 -0000 Message-ID: <20060119153246.16055.qmail@web402.biz.mail.mud.yahoo.com> Received: from [67.176.184.39] by web402.biz.mail.mud.yahoo.com via HTTP; Thu, 19 Jan 2006 07:32:46 PST Date: Thu, 19 Jan 2006 07:32:46 -0800 (PST) From: Tim OBrien Subject: Re: [SCXML] SCXMLSerializer and package reorganization (WAS: [scxml] a few observations, issues before release) To: Jakarta Commons Developers List In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N --- 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. > > > > > > 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). > > > > > 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