commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dion Gillard <dion.gill...@gmail.com>
Subject Re: XML Im-/Ex-porter into Commons Sandbox
Date Mon, 11 Oct 2004 07:49:56 GMT
If you're looking for something simple, you may want to check out
http://xstream.codehaus.org/ as well.


On Mon, 11 Oct 2004 08:35:01 +0200, Oliver Zeigermann
<oliver.zeigermann@gmail.com> wrote:
> Hi Simon,
> 
> I really appreciate your input, thanks again :)
> 
> On Mon, 11 Oct 2004 19:15:11 +1300, Simon Kitching
> <simon@ecnetwork.co.nz> wrote:
> >
> > >
> > > As I already tried to explain. Both are soooooo different. No need for
> > > any worries...
> > > They even serve a different audience I guess. Digester is good for
> > > people who do not want to see any XML stuff and what Java objects,
> > > with xmlio you are closer to the guts of SAX and XML.
> >
> > I don't actually see that they are that different.
> >
> > You can use Digester in a manner very similar to the way xmlio is used.
> > This is not the way Digester is "marketed" in its examples but it is
> > still quite valid:
> >
> > class Foo {
> >
> >   private class HandleWidget extends Rule {
> >         public void begin(...) {
> >                 // code to do stuff when a widget tag is found
> >         }
> >   }
> >   ...
> >
> >   digester.addRule("/root/widget", new HandleWidget());
> >   digester.addRule("/root/gadget", new HandleGadget());
> >
> >   xmlReader.setContentHandler(digester);
> >   xmlReader.parse(input);
> > }
> >
> > Here's the xmlio equivalent (I think...)
> >
> > class Foo {
> >   private class MySimpleImportHandler implements SimpleImportHandler {
> >     public void StartElement(...) {
> >       if (path.equals("/root/widget) {
> >         // code to do stuff when a widget tag is found
> >       }
> >       else if (path.equals("/root/gadget") {
> >         // code to do stuff when a gadget tag is found
> >       }
> >   }
> >
> >   simpleImporter.addSimpleImportHandler(new MySimpleImportHandler());
> >   saxParser.setContentHandler(simpleImporter);
> >   saxParser.parse(input);
> > }
> 
> Agreed.
> 
> > In other words, Digester *can* be used as a "light wrapper around SAX".
> > The begin/body/end methods of a custom Rule class are basically the SAX
> > callbacks; when using Digester in this style, Digester is really just an
> > "event dispatcher" routing each sax event from a single ContentHandler
> > class to zero or more relevant rule classes to avoid having big
> > cascading if/then statements in the ContentHandler class.
> >
> > It wouldn't take too much work to provide xmlio's convenient feature of
> > passing the attributes into the body/end methods as well as the begin
> > method. It doesn't need to provide xmlio's Path functionality because
> > the "event dispatching" mostly removes the need for that.
> >
> > The problem at the moment is it brings with it so many inter and intra
> > library dependencies that there isn't a light *distributable package*
> > containing just the core Digester classes.
> >
> > I'm certainly not trying to criticise xmlio; I'm just concerned that
> > multiple projects will both dilute the available developer pool and
> > confuse potential users. And all that extra work - unit tests, project
> > website, etc! If the projects are truly providing different
> > functionality, well there's no issue. But as I understand xmlio now, I
> > think that exactly the same goal can be achieved with almost exactly the
> > same amount of custom code with both libs.
> >
> > Oliver: do you feel that the fact that Digester does "sax event
> > dispatching" while xmlio doesn't really make the lib feel different to
> > you? (honest question, it is a slightly different paradigm, like OO vs
> > procedural). Is there something else that makes you feel Digester is
> > fundamentally different from xmlio?
> 
> Simplicity and obviousness, having all parts of the code and the data
> that are associated at one spot. Next is performance and actual
> complexity of code. Next is amount of created objects.
> 
> Still, these are just considerations that come from my personal taste.
> When rules become a bit more complicated, it might become pretty hard
> to understand what is going on in the guts.  A large block of if /
> else statements might not be what people - including myself - would
> call exactly elegant, but it is obvious with no secrets.
> 
> Oliver
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> 
> 


-- 
http://www.multitask.com.au/people/dion/

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