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,That can be changed :-)
Simon
PS: I'm not a committer/maintainer, just another interested user...
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
