commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel Florey" <daniel.flo...@web.de>
Subject Re: XML Im-/Ex-porter into Commons Sandbox
Date Mon, 11 Oct 2004 12:28:09 GMT
"Jakarta Commons Developers List" <commons-dev@jakarta.apache.org> schrieb am 11.10.04
09:50:48:
> 
> If you're looking for something simple, you may want to check out
> http://xstream.codehaus.org/ as well.

I just checked it out and it looks very sweet! Very clean approach (looks simpler to me as
betwixt because there are no xml-mapping files).
Thanks for the link! I've implemented something similar (but ugly and half-finished) in the
Slide Projector. Hope I can replace it...
Cheers,
Daniel

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


________________________________________________________________
Verschicken Sie romantische, coole und witzige Bilder per SMS!
Jetzt neu bei WEB.DE FreeMail: http://freemail.web.de/?mc=021193


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