commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Heimann <>
Subject Re: Re: digester 2.0 [WAS Re: [digester] [PROPOSAL] More pattern matching flexibility]
Date Tue, 03 Sep 2002 16:50:56 GMT
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.

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

Here are the methods the deal with namespace support (from my patch):

   * Associate a prefix with the given namespace uri. The prefix
   * can be used in all further calls of the {@link #add} method to refer
   * to this namespace uri.
   * @throws IllegalArgumentException if prefix is already
   * registered 
   * @throws IllegalArgumentException if the empty string is given
   * as a prefix.
  public void registerNamespacePrefix(String prefix, String namespaceURI);

   * Remove the mapping between the given prefix and its 
   * associated namespace uri.
   * @throws IllegalArgumentException if prefix has not been registerd.
  public void unregisterNamespacePrefix(String prefix);
   * Get the namespace uri associated with the given prefix.
   * @throws IllegalArgumentException if the prefix has not been
   * registered previously.
  public String getNamespaceURI(String prefix); 

   * Check if <code>prefix</code> is registered as a namespace
   * prefix.
  public boolean isRegisteredPrefix(String prefix);

  public Map getNamespaceMappings();   

   * Set the namespace uri that should be used if no namespace prefix
   * is given for an element in a pattern. 
   * If <code>namespaceURI == null</code> or 
   * <code>"".equals(namespaceURI)</code>, the pattern element 
   * will have no associated namespace.
  public void setDefaultNamespaceURI(String namespaceURI);
   * Get the default namespace uri.
   * @see #setDefaultNamespaceURI
  public String getDefaultNamespaceURI(); 


Stefan Heimann       |
Brandensteinstr. 5   |
D-79110 Freiburg     |

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

View raw message