commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From robert burrell donkin <robertburrelldon...@blueyonder.co.uk>
Subject Re: [digester] warning of unknown elements and attributes
Date Mon, 28 Apr 2003 16:56:55 GMT

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.

>> rather than add an extra method to the Rules interface, i'd rather 
>> create a new class that wraps an existing implementation and fires non 
>> matching rules whenever the wrapped implementation returns no matches. i 
>> prefer this mechanism since it means that we don't have to change the 
>> interface or the contract for existing Rules implementations.
>
> Sounds good to me.

cool.

- robert


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