forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Unico Hommes" <Un...@hippo.nl>
Subject RE: LocationMapModule
Date Fri, 17 Oct 2003 15:41:30 GMT


Nicola Ken Barozzi wrote:
> 
> Unico Hommes wrote:
> >
> ...
> > 
> > OK, what about creating a special purpose matcher:
> > 
> > class WildcardLocationMapMatcher extends AbstractWildcardMatcher {
> >   
> >     /**
> >      * Return the LocationMapModule hint concatenated with 
> the request URI.
> >      */
> >     protected String getMatchString(Map objectModel, 
> Parameters parameters) {
> >         
> >         String hint = 
> parameters.getParameter(LocationMapModule.HINT_PARAM);
> >         String uri = 
> ObjectModelHelper.getRequest(objectModel).getSitemapURI();
> > 
> >         return hint + uri;
> >     }
> > }
> > 
> > And have an equivalent one for regular expression matching. 
> Actually, I think this is exactly what you meant isn't it?
> 
> Hmmm, not sure... how would you use this differently from the current 
> parameter matcher?
> 

The LocationMap.HINT_PARAM parameter is not passed in from the locationmap.xml but is already
passed in from the LocationMap. So actually it would be like so:

<locationmap>

  <components>
    <matchers default="lm">
      <matcher name="lm" type="o.a.c.matching.LocationMapMatcher" />
    </matchers>
  </components>

  <locator>
    <match pattern="**.html">
      <match pattern"style/**.html">
        <location src="somewhere/styles/{1}.xsl" />
      </match>
      <match pattern="source/**.html">
        <location src="somewhereelse/content/{1}.xml" />
      </match>
    </match>
  </locator>

</locationmap>

> You see, what I want is not to have to extend the current 
> matchers, but 
> to be able to use them as-is. Since the most important 
> matchers match to 
> the request URI, it seemed natural to me to add this info to 
> these matchers.

I see three, two reqexp flavors and one wildcard one.

> 
> In any case, there is another possibility: a 
> Location2RequestWrappingMatcher.
> 
> How does it work?
> 
> class Location2RequestWrappingMatcher:
> 
>    matcherToUse;
> 
>    void configure(x):
>       getMatcherToUse(x);
> 
>    Map match(...):
>       return matcherToUse.match(wrapRequestURI(hint + uri),...);
> 
> 
> In this way we can declare the matcher to use another matcher 
> underneath, and to simply expose the location hint as the request URI.
> 

It's a possibility. But I don't think it's needed. Remember there are only three matchers
that actually would have to be wrapped this way. If you extend these and add the four lines
of code that would be needed to make them compatible with the locationmap, you'd also get
rid of the extra configuration section you'd have in the case of a wrapper matcher.

> So it's easy for users to make any matcher that matches to 
> the request 
> URI be used to match locations.
> 
> Basically I'm using composition instead of inheritance, as I 
> can control 
> composition during the setup phase and pass in the matcher as an 
> interface (Matcher).
> 
> Pfew, that was a really twisted description, hope you make 
> sense of it ;-)

I get it. But I doubt there will be so many matchers to wrap/compose in order to make it pay
off to have that additional configuration requirement.


> 
> -- 
> Nicola Ken Barozzi                   nicolaken@apache.org
>              - verba volant, scripta manent -
>     (discussions get forgotten, just code remains)
> ---------------------------------------------------------------------
> 
> 
> 

Mime
View raw message