Mailing-List: contact commons-user-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Users List" <commons-user@jakarta.apache.org>
Message-ID: <3F8E4D30.2000006@wanadoo.nl>
Date: Thu, 16 Oct 2003 09:48:00 +0200
From: Matthijs Wensveen <mrw@wanadoo.nl>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
 rv:1.6a) Gecko/20030930
MIME-Version: 1.0
To: Jakarta Commons Users List <commons-user@jakarta.apache.org>
Subject: Re: [digester] RFE - Digester.startElement could use a callback
References: <Pine.LNX.4.50.0310151028590.16896-100000@petea>
 <1066254759.23922.27.camel@PCSIMON.ecnnz.ecnetwork.co.nz>
 <3F8DFF4C.9040005@apache.org>
In-Reply-To: <3F8DFF4C.9040005@apache.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi,
Steve, you say that you want to put out the error message if there is no 
matching rule. One way of doing this is calling digester.setLogger(..). 
Of course, this might not be what you want because in this way you have 
little control over the error message (except if you create your own 
Logger which parses the log messages and does something with them, but 
that is rather far-fetched).
Seeing as Digester is more an API than a 'product' (at least that is how 
I feel about Digester), it would be more logical to throw exceptions 
rather than log error messages. This is the de-facto way to go with APIs.
Having no matching rules could mean that an unchecked exception is 
thrown. Normal users can let the exception just pass by, while 
interested users can catch the exception.
More serious exceptions could be checked exceptions, however, by 
implementing checked exceptions Digester would lose backwards compatibility.

Just my 2 eurocents,
Matthijs.

Craig R. McClanahan wrote:

> Simon Kitching wrote:
>
>> Hi Steve,
>>
>> Are you saying that in the xml you are parsing, you expect to have at
>> least one Rule object defined for every XML element? And that you want
>> to know if there are any unexpected xml elements in the input so you can
>> report an error?
>>
>> If this is the case, then an alternative solution is to create an xml
>> schema for your input, and validate against that schema.
>>
>> I don't think many users of Digester will care whether an element has no
>> rules or not, ie your suggested feature is not likely to be used often.
>> So if there is a way to achieve what you want without adding any code it
>> would probably be desirable.
>>
>> I do think that a generic "callback" mechanism for handling situations
>> where Digester encounters unusual situations or error situations may be
>> useful. There are several places where Digester throws an exception (see
>> calls to createSAXException) where it might be nice to invoke
>> caller-provided code ala org.xml.sax.ErrorHandler. If a mechanism were
>> to be added for this, then adding a callback for "no rules" might be
>> justified too; however I can't see adding a mechanism for *just* the "no
>> rules" case as being worth it....not enough people would want to use
>> this feature.
>>
>> Of course if you can persuade people that your reason for wanting this
>> feature is one likely to be shared by other people, that would add a lot
>> of weight.
>>
>> Anyone else got any thoughts on this?
>>  
>>
>
> Simon accurately captures my feelings on the subject ... in my 
> experience with the primary use case for which Digester was created 
> (parsing configuration files), having any matching Rules is the 
> exception rather than the Rule :-).
>
> That being said, I also agree with the notion of a Digester 2 with a 
> much richer model of "this is something strange that happened, you 
> might be interested" type events.  In effect, it would turn Digester 
> into a general purpose easier-to-use version of SAX, more than just a 
> way to pull a little data out of XML documents -- and that would be a 
> Good Thing (tm).
>
>> Cheers,
>>
>> Simon
>>
>> PS: I'm not a committer/maintainer, just another interested user...
>>  
>>
> That can be changed :-)
>
> Craig
>
>>
>> On Thu, 2003-10-16 at 06:38, Steve Drach wrote:
>>  
>>
>>> Near the end of the startElement method, we see this:
>>>
>>>        List rules = getRules().match(namespaceURI, match);
>>>        if ((rules != null) && (rules.size() > 0)) {
>>>          ...
>>>        } else {
>>>            if (debug) {
>>>                log.debug("  No rules found matching '" + match + "'.");
>>>            }
>>>        }
>>>
>>> It would be nice if I could register an interface implementation that
>>> contains a method that gets invoked in the else clause, so I can know
>>> if no rules match the name.  That way I can put out an error message if
>>> I want.  Somthing like this:
>>>
>>>
>>>        } else {
>>>            callback.notify(name);
>>>            if (debug) {
>>>                log.debug("  No rules found matching '" + match + "'.");
>>>            }
>>>        }
>>>
>>> Of course, callback is not a very good name, but you get the idea.
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail: commons-user-help@jakarta.apache.org
>>>
>>>
>>>   
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: commons-user-help@jakarta.apache.org
>>  
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-user-help@jakarta.apache.org
>
>
>


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