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 Wed, 23 Apr 2003 16:40:09 GMT
(sorry for the delay, i've been boating.)

On Friday, April 18, 2003, at 09:58 AM, James Strachan wrote:

> On Thursday, April 17, 2003, at 11:13  am, robert burrell donkin 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 was thinking about creating a new Rules implementation which contained 
this functionality (rather than adding anything to the basic interface). 
this would wrap another Rules implementation but fire the non-matching 
rules whenever the wrapped implementation returns no rules.

i'll see if i have time to an implementation along these lines.

> Though this only works for elements. I'd like a way of handling unknown 
> attributes too...

true

>> i like the idea of a callback method on digester for Rule 
>> implementations that cannot execute correctly. this would give a lot 
>> more flexibility for digester subclasses (for example) to vary this 
>> behaviour from logging to doing clever stuff using (for example) the 
>> Document Locator. maybe a little though about the interface for this 
>> method may pay dividends in the long run (i'm want to cut a new release 
>> very soon since the latest release has a few incompatibilities). but i'd 
>> say we only need one since the no-matching-rules issue can (i think) be 
>> handled by creating a Rules implementation along the lines i suggest 
>> above.
>
>
> I think adding support for 'non matching rules' (if you can think of a 
> better name, be my guest :) will handle elements nicely; though it doesn'
> t quite work for attributes.

true

> Maybe the simplest patch for now is to have 2 callback methods on 
> Digester (with default implementations that just log a warning) something 
> like
>
> 	// handle unmatched elements
> 	onUnmatchedElement(String uri, String localName, Attributes 
> attributes);
>
> 	// handle unmatched attribute values
> 	onUnmatchedAttribute(String elementURI, String elementLocalName, 
> String attributeURI, String attributeLocalName, String attirbuteValue);
>
>
> Then derived Digester implementations can handle wrong element/attributes 
> in the same way?

there are other ways that an xml document could be invalid (in digester 
terms) as well as there simply being no rule registered for a particular 
pattern. for example, a CallMethodRule might call a method which requires 
three parameters and three CallParamRule's are registered to "bean/alpha", 
"bean/beta", "bean/gamma" patterns (say). if each <bean> element does not 
contain <alpha>, <beta> and <gamma> tags then then xml should be invalid.

so maybe we do require generic callbacks for elements as well as 
attributes :)

(i'm still keen to add the Rules implementation i outlined above since i 
think that it'd be a nice feature.

> Am starting to think that handling of unknown element/attributes are a 
> little different to normal element-based digester rules and so maybe 
> should be handled differently. Maybe the above 2 methods could be a 
> pluggable Strategy?

a pluggable strategy sounds like a good idea to me :)


i'm planning on cutting a digester 1.5 release ASAP based on the fact that 
1.4.1 is not fully backwards compatible with digester 1.3. i think that it'
d be a good idea to leave all this stuff until after the release so that 
we're not rushed into adding something that isn't quite right.

- 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