commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Lenz <>
Subject Re: digester 2.0 [WAS Re: [digester] [PROPOSAL] More pattern matching flexibility]
Date Wed, 04 Sep 2002 15:51:53 GMT
After some more fiddling I think we can get this implemented without 
breaking binary compatibility. Well, almost: The field Digester.rules is 
the only remaining problem. It'd need to be removed or at least ignored 
by Digester, both possibly breaking clients who used the field directly 
to get/set the Rules instance from a subclass.

I've got Digester working with the Matcher interface, and all of the 
unit tests still run without modifications.

I'm not sure where to go from here... One could argue that 
backwards-compatibility is pretty much preserved with the changes, so 
this stuff could even go into a 1.x release, and a subsequent 2.0 
release would be a cleanup release, removing all the deprecated stuff.

Does anyone else have opinions on this? (I know, commons & patience etc. 
;-)) Should I just send a (large) patch so someone can check it out?

Christopher Lenz wrote:
> Christopher Lenz wrote:
>> Note that the Matcher doesn't store the Rules themselves, that will be 
>> the responsibility of Digester. Digester will just request the matched 
>> patterns from the Matcher and then lookup the corresponding rules in a 
>> map (for example).
> Okay, stopping to ignore a test failure with universal matching ;-), I 
> realized that this won't work, as the clear association between pattern 
> and rule is lost. So the Matcher needs to know about the rules:
>   public interface Matcher extends ContentHandler {
>     // adds a rule with a matching pattern.
>     public void add(String pattern, Rule rule);
>     // removes all rules
>     public void clear();
>     // Returns the list of rules that match the current document
>     // context, in the order they've been added.
>     public List matches();
>     // Returns the list of all rules in the order they've been added.
>     public List rules();
>   }
> So the Matcher would not be as fundamentally different from the Rules 
> interface as I first though, but that makes the RulesAdapter easier to 
> implement ;-)
> The matches() method could also accept a namespaceURI argument so that 
> the returned rules are limited to that namespace. But as that 
> functionality would be common to all Matcher implementations, I'd rather 
> put it in Digester. However I've also not put much thought into that 
> aspect yet.

Christopher Lenz
/=/ cmlenz at

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

View raw message