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
<[EMAIL PROTECTED]> wrote:
> Hi Simon,
>
> I really appreciate your input, thanks again :)
>
> On Mon, 11 Oct 2004 19:15:11 +1300, Simon Kitching
> <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
--
http://www.multitask.com.au/people/dion/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
