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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
