commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Kitching <si...@ecnetwork.co.nz>
Subject Re: [Digester] New rules
Date Sun, 07 Mar 2004 20:15:39 GMT
On Sun, 2004-03-07 at 11:37, robert burrell donkin wrote:
> On 4 Mar 2004, at 07:59, Jörg Schaible wrote:
> > Simon Kitching wrote on Wednesday, March 03, 2004 11:54 PM:
> 
> <snip>
> 
> >> In some ways it's nice,
> >> because it is obvious to users, but of course every rule
> >> added to Digester increases the jar size, the API complexity,
> >> and the maintenance load.
> >
> > Will this be addressed in Digester2 ? I was really astonished, that 
> > the digester itself has a method for any known rule. This makes the 
> > usage of self-written ones not too obvious. Personally I would 
> > eliminate/deprecate all of them and just offer addRule. But this is 
> > getting OT for this thread, for D2 I have other annotations anyway :)
> 
> users pretty much demand that these methods are added.
> 
> the problem is that these methods do introduce an unhelpful coupling 
> and add to the footprint. it's just one of those things that's 
> unfortunate but probably not positively harmful.

It's also quite consistent with the DOM design, where a Document object
also acts as a factory for the different node types.

Admittedly, the DOM approach has the justification that all the Node
classes are abstract, and the Document returns instances of some
concrete implementation (a true factory) while Digester's rules are all
concrete already. 

However the convenience factor of having addXXX methods on the digester
obejct itself is pretty high, while not removing the ability of users to
add extra rules as they wish. Personally, I think the convenience is
worth the extra work. 

> 
> one of the solutions that i've been turning over in my mind would be to 
> introduce a DigesterEngine superclass that would be a minimal 
> stripped-down version without the dependency on those rules. that could 
> be done without breaking backwards compatibility. on the other hand, 
> i've never felt motivated to add this since it's not really an itch for 
> me.

I think this is a fine idea. In fact, if you look at the (only partially
complete) ruby digester project at
http://rubyforge.org/projects/xmldigester, this is exactly what I did. A
Digester class and a RuleFactory class are defined separately, then the
RuleFactory class is used as a mixin. Unfortunately, this doesn't work
quite as nicely in Java :-).

I see you made a comment about "D2". I've also got some ideas about what
might be done for Digester version 2.0. In fact, the Ruby version has
got some of these ideas already implemented. I'd be interested in
hearing your ideas sometime soon (maybe after the 1.6 release gets out
the door?).

How about we start a Wiki page where these ideas can be jotted down for
later reference?

Regards,

Simon


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