Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Date: Fri, 18 Apr 2003 09:58:25 +0100
Subject: Re: [digester] warning of unknown elements and attributes
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v552)
From: James Strachan <james_strachan@yahoo.co.uk>
To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Content-Transfer-Encoding: 7bit
In-Reply-To: <30AB7612-70BD-11D7-9680-003065DC754C@blueyonder.co.uk>
Message-Id: <EA45285A-717B-11D7-820C-000A959D0312@yahoo.co.uk>


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

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