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]
