commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean-Francois Arcand <>
Subject Re: digester 2.0 [WAS Re: [digester] [PROPOSAL] More pattern matching flexibility]
Date Tue, 03 Sep 2002 17:22:03 GMT

Christopher Lenz wrote:

> Hi Jean-Francois,
> Jean-Francois Arcand wrote:
> > Not sure if I can join the discussion ;-)....anyway, here is some
> > ideas for Digester 2.0. We should also add some methods for:
> >
> > - add getter/setter for setting the ContentHandler (if someone doesn't
> > want to use the DigesterContext)
> > - add getter/setter for setting the ErrorHandler and the DTDHandler.
> > Having experienced hard problems with Xerces 2.0.1 - 2.0.2 and XML
> > Schema, being able to set my own ErrorHandler will be usefull.
> I'm probably missing something, but here goes... why can't you just use:
>   digester.getXMLReader().setContentHandler()
>   digester.getXMLReader().setDTDHandler()
>   digester.getXMLReader().setErrorHandler()
> ?

True, but in order to hide the Parser complexity, we should add those 
methods directly on the Digester API  itself (there is actually 
Digester.setEntityHandler and Digester.getEntityHandler available). It 
will follow Digester other setter/getter e.g to set a property,you can 
do Digester.setProperty(), but also 
digester.getXMLReader().setProperty() [I know both are the same, but I 
tougth it was easier to hide the XMLReader stuff]

> For instance, I've implemented a Rule that replaces the ContentHandler 
> in Digester with one that creates a DOM DocumentFragment, pushes it on 
> the stack, and returns control to Digester when an end tag matching 
> the start tag is encountered.
>> It might be a good idea to have a method on the Matcher interface like
>> public void setErrorHandler(ErrorHandler eh)
>> So different Matcher can customize their own ErrorHandler...
> The Matcher interface should probably have set/getDigester() methods to
> be able to access the XMLReader used by Digester.


>> That will standardize the actual wrapper around the 
>> XMLReader....right now, only the EntityResolver is available for 
>> clients.
> I don't quite understand what you mean here...

Sorry, my english....right now, some XMLReader methods are available at 
the Digester level (ex: setFeature, getFeature, setProperty, 
getProperty). I think we need to wrap all XMLReader method, or hide the 
actual one. Right now, I'm able to do:

Digester d = new Digester();

I would prefer doing




Agains, both way works fine. I think we have to decide to support only 
one way of accessing XMLReader's methods.

-- Jeanfrancois

> [...]

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

View raw message