forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <>
Subject Re: LocationMapModule
Date Fri, 17 Oct 2003 15:06:00 GMT
Unico Hommes wrote:
> Nicola Ken Barozzi wrote:
>>Unico Hommes wrote:
>>>Pass it where? #lm:name is just the key to a Parameter that 
>>holds the input module argument /my/path . The Matcher 
>>interface does not allow the passing of a src attribute for instance:
>>Of course, a matcher /usually/ needs _two_ things, a pattern and 
>>something to match it against.
>>But if we add somehow the inputmodule argument to the request URI...
> It's possible. We could wrap the original Request and supplement the
> URI (because the the request URI is read-only); But maybe its not the
> most convenient solution. I see your point though that having to specify
> a special parameter is not very clear. I had already been considering a
> seperate matcher that hides that detail (would be no more than a few
> lines of code). I would prefer that over modifying the request uri.


>>Basically it's about adding the inputmodule part to the request URI.
> But in the case of semantic linking where the input module argument
> is the only thing to look at that would be very inconvenient.


>>>IIUC we could do this with the current implementation:
>>><match pattern="**.html">
>>>  <match pattern"style" type="parameter">
>>>    <location src="somewhere/styles/{1}" />
>>>  </match>
>>>  <match pattern="source" type="parameter">
>>>    <location src="somewhereelse/content/{1}" />
>>>  </match>
>>Correct, but we need a special matcher, while in my proposal 
>>we use only 
>>standard matchers, and can also use regexp and wildcard 
>>matching in the 
>>locator hint part.
> B.t.w. there's also a regexp parameter matcher.

Yeah, but duplicating matchers is not a really nice thing... but if we 
have to only duplicate a couple of them...

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

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.

In any case, there is another possibility: a 

How does it work?

class Location2RequestWrappingMatcher:


   void configure(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.

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 ;-)

Nicola Ken Barozzi         
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)

View raw message