commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Lenz <>
Subject Re: digester 2.0 [WAS Re: [digester] [PROPOSAL] More pattern matching flexibility]
Date Tue, 03 Sep 2002 17:08:30 GMT
Stefan Heimann wrote:
> On Tue, Sep 03, 2002 at 05:13:25PM +0200, Christopher Lenz wrote:
>>Christopher Lenz wrote:
>>>Note that the Matcher doesn't store the Rules themselves, that will be 
>>>the responsibility of Digester. Digester will just request the matched 
>>>patterns from the Matcher and then lookup the corresponding rules in a 
>>>map (for example).
>>Okay, stopping to ignore a test failure with universal matching ;-), I 
>>realized that this won't work, as the clear association between pattern 
>>and rule is lost. So the Matcher needs to know about the rules:
>>  public interface Matcher extends ContentHandler {
>>    // adds a rule with a matching pattern.
>>    public void add(String pattern, Rule rule);
>>    // removes all rules
>>    public void clear();
>>    // Returns the list of rules that match the current document
>>    // context, in the order they've been added.
>>    public List matches();
>>    // Returns the list of all rules in the order they've been added.
>>    public List rules();
>>  }
> What about namespaces in a pattern? There must be a way to register
> the uri-prefix mapping.

I had such methods in the interface at the beginning...

However I think that both SimpleMatcher (currently RulesBase) and 
ExtendedMatcher (currently ExtendedBaseRules) should not have the 
namespace prefix matching support built-in, simply because not many 
people need it, and it adds a lot of overhead (i.e. having to deal with 
a stack of local names and namespace URIs, or a QNameList as in your 
patch).  Neither would they directly support any of the other matching 
features I listed in my proposal. That would be left for special matchers.

So, if we add something like a NamespaceAwareMatcher (stupid name, just 
an example ;-)), you could have the namespace-prefix-registering methods 
directly in that class. The API client would have to use the class 
directly anyway, as in:

   NamespaceAwareMatcher matcher = new NamespaceAwareMatcher();
   matcher.addNamespace("foo", "");

Having the method(s) in the base interface will probably just confuse users.

>>So the Matcher would not be as fundamentally different from the Rules 
>>interface as I first though, but that makes the RulesAdapter easier to 
>>implement ;-)
>>The matches() method could also accept a namespaceURI argument so that 
>>the returned rules are limited to that namespace. But as that 
>>functionality would be common to all Matcher implementations, I'd rather 
>>put it in Digester. However I've also not put much thought into that 
>>aspect yet.
> I would suggest not to support such a namespaceURI argument. Instead,
> we could provide a setDefaultNamespaceURI. If the default namespace
> uri is not null, all elements in a pattern will be treated as
> contained in that namespace. 

Hmm... but the namespaceURI argument in Rules.match() is used to exclude 
rules that don't match the current namespace, or if (namespaceURI == 
null) to include all rules. This is to support the namespace specific 
rule(set)s. I don't see what that has to do with defining a default 

Christopher Lenz
/=/ cmlenz at

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

View raw message