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.
Cool.
>
>> 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.
James
-------
http://radio.weblogs.com/0112098/
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
|