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 17:20:39 GMT
On Tue, Sep 03, 2002 at 07:08:30PM +0200, Christopher Lenz wrote:
> 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", "http://www.foo.bar/foo");
>   digester.setMatcher(matcher);
> 
> Having the method(s) in the base interface will probably just confuse users.

you are probably right. I could implement this NamespaceAwareMatcher
(if you like), based on my patch.

> 
> >>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 
> namespace.

ok, if we do not include the methods dealing with namespaces, we
should leave the namespaceURI argument as it is. 

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