commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean-Francois Arcand <>
Subject Re: digester 2.0 [WAS Re: [digester] [PROPOSAL] More pattern matching flexibility]
Date Wed, 04 Sep 2002 16:00:30 GMT

Christopher Lenz wrote:

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

Not sure I like the "pretty much preserved" :-) Like you said, the 
Digester.rules is a problem (maybe small, maybe not). I would prefer 
adding your work under 2.0.

-- Jeanfrancois

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

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

View raw message