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 Fri, 18 Apr 2003 08:58:25 GMT

On Thursday, April 17, 2003, at 11:13  am, robert burrell donkin wrote:

> hi james
> i like the sound of these ideas :)

Cool; glad its not just me :)

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

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

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

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 

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

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?

> BTW don't forget to add your name to the STATUS file. the more the 
> merrier :)

Done :)

> - robert
> On Wednesday, April 16, 2003, at 12:49 PM, James Strachan wrote:
>> I'd like digester to be able to warn if a user makes a typeo in an 
>> XML document, typing the wrong element or attribute name. Often 
>> digester files have a dynamic schema based on the classes used (e.g. 
>> when overriding the implementation class of a bean, the properties 
>> can change)
>>  so using traditional fixed schema/DTD approaches don't work.
>> From looking at the current digester code this looks fairly easily 
>> possible; I was just checking if anyone had figured out a way to do 
>> this anyway using the current RuleSet stuff. e.g. can you specify a 
>> rule to be fired only if no other rules are fired?
>> I was suspecting that the above wasn't possible and so was thinking 
>> of adding 2 callbacks into Digester for when no rule is found, or 
>> when some rules (like SetObjectProperties) finds an unknown attribute 
>> - so that applications can decide how best to treat these warning 
>> conditions. Then the default implementation of these methods could 
>> just do some logging of a warning to commons-logging.
>> Has anyone attempted something like this before (just trying to avoid 
>> duplicating work). Or any other thoughts on this?


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

View raw message