commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <craig...@apache.org>
Subject Re: [digester] warning of unknown elements and attributes
Date Mon, 28 Apr 2003 17:25:11 GMT


On Mon, 28 Apr 2003, robert burrell donkin wrote:

> Date: Mon, 28 Apr 2003 17:56:55 +0100
> From: robert burrell donkin <robertburrelldonkin@blueyonder.co.uk>
> Reply-To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
> To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
> Subject: Re: [digester] warning of unknown elements and attributes
>
>
> 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.
>

+1 on decorating base classes instead of modifying interfaces.

> - robert

Craig

>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>

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