commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Kitching <>
Subject Re: XML Im-/Ex-porter into Commons Sandbox
Date Mon, 11 Oct 2004 06:15:11 GMT

> 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());


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());

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?



To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message