commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Heimann <m...@stefanheimann.net>
Subject Re: Re: digester 2.0 [WAS Re: [digester] [PROPOSAL] More pattern matching flexibility]
Date Tue, 03 Sep 2002 16:43:16 GMT
On Tue, Sep 03, 2002 at 03:56:43PM +0200, Christopher Lenz wrote:

> Now, there might be a simpler and yet more flexible design... what if 
> someone wanted to create a Matcher that understands full-blown XPath 
> expressions. In that case DigesterContext would be the limiting factor, 
> as the Matcher would not have access to - for example - the attributes 
> of the parent element. In other cases, the DigesterContext might have 
> more info than the Matcher requires. The algorithm in the current 
> RulesBase is enough for many use-cases and only needs a simple string to 
> match against. Here the DigesterContext adds unneeded overhead.
> 
> So, my idea was to make the Matcher a SAX ContentHandler and not pass a 
> DigesterContext (or something similar) at all:
> 
>   public interface Matcher extends ContentHandler {
>       ...
> 
>       // return all patterns that match the current XML document
>       // context
>       public List matches();
> 
>       ...
>   }
> 
> Digester in turn would call all the Matcher's ContentHandler methods 
> from it's own ContentHandler implementation methods. The Matcher could 
> get all the information (and *only* the information) about the parsed 
> XML that it actually needs to perform it's matching tasks.
> 
> I've done some experimenting with a RulesAdapter (i.e. a class that 
> implements Matcher but wraps around a Rules implementation), and it 
> looks like we could get away with almost no breaking API changes.
> 
> Again, I actually like this approach much better than my own 
> DigesterContext idea... it seems cleaner, leaner and more flexible. What 
> do you think?

The idea is great. What I don't like is that the matcher has to deal
with collection the information. I think its better to separate the
collection of information and the matching algorithm. What about

public interface Matcher {
  
  // ..

  /**
   * Returns the content handler that is used to collect
   * the information which is needed for matching.
   */
  public ContentHandler getInformationCollector();
}

Bye,
  Stefan

-- 
Stefan Heimann       | http://www.stefanheimann.net
Brandensteinstr. 5   | http://www.cantaloop.org
D-79110 Freiburg     | http://cvsshell.sourceforge.net

--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message