commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Strachan <>
Subject Re: [digester] warning of unknown elements and attributes
Date Tue, 29 Apr 2003 12:45:51 GMT

On Monday, April 28, 2003, at 05:56  pm, robert burrell donkin wrote:

> On Monday, April 28, 2003, at 05:01 PM, James Strachan wrote:
>> On Monday, April 28, 2003, at 01:59  pm, robert burrell donkin wrote:
>>> On Friday, April 18, 2003, at 09:58 AM, James Strachan wrote:
>>> <snip>
>>>>> the way i'd prefer the no-matching-rules issue to be resolved 
>>>>> would be through a new Rules implementation. this would wrap 
>>>>> another Rules implementation and allow rules to be registered 
>>>>> which would be called when the wrapped implementation returns no 
>>>>> matches. i think that this would be easy to implement (i might 
>>>>> even get round to it soonish), be useful in other situations (as 
>>>>> well as validation) and allow the flexibility to mix-and-match 
>>>>> this behaviour with existing Rules implementations.
>>>> Just to check we're on the same page; we could add a method to 
>>>> Rules to get the non-matching rules. Something like
>>>> public void addNonMatchingRule(Rule);
>>>> public List getNonMatchingRules();
>>>> And these non-matching rules would be fired by digester if no 
>>>> matching rules are found for a certain element.
>>> i've knocked up a class to make the discussions a bit easier.
>> Cool. Wanna go ahead and commit it to CVS?
> yep.


>> Another approach could be to merge this functionality into the base 
>> class (RulesBase) since it already handles the case where no rules 
>> match - but right now it returns an empty list in this case - it'd be 
>> trivial to patch this to merge in the logic from the class you've 
>> sent.
> inheriting from RulesBase is inconvenient for some kinds of Rules 
> implementations (RegexRules, for example, inherits from 
> AbstractRuleImpl). using a decorator means that this functionality can 
> be easily added to any implementation.

We could add it to AbstractRuleImpl instead then :). Its only adding 1 
new property, or adding 1 new factory method to create the unmatched 
rule list. Though I'm not too bothered either way really  adding this 
feature into all Rules implementations seems a little simpler from an 
end user perspective - no big deal though.


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

View raw message