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 14:12:49 GMT
Unico Hommes wrote:

> Nicola Ken Barozzi wrote:
>>Unico Hommes wrote:
>>>  + -->
>>>  <components>
>>>    <matchers default="parameter">
>>>      <matcher 
>>>        name="parameter" 
>>>        src="org.apache.cocoon.matching.WildcardParameterMatcher">
>>>        <!-- 
>>>          + #lm:name is a special parameter that is passed into 
>>>          + the Matcher by the LocationMap implementation.
>>>          + It identifies the name string the module was called
>>>          + with. For example when calling the module as follows:
>>>          + {lm:/my/virtual/path} the parameters value will
>>>          + be /my/virtual/path .
>>>          + -->
>>Can't we simply pass what is after the inputmodule colon?
> 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:
> interface Matcher {
>   Map match(String pattern,Map objectModel,Parameters parameters);
> }
> The only way to pass the input module argument to the matcher is via a parameter.
> Consider for instance the most commonly used matcher, WildcardURIMatcher, it does not
get passed a String so it can match against it but it looks it up on the objectModel argument:
> Request request = ObjectModelHelper.getRequest(objectModel);
> String stringToMatch = request.getURI();

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

>>Ok, so you have already added the <component> section from the start; 
>>this is good in any case so we are not hooked on the components being 
>>declared in the sitemap.
> But the initial reason for doing this was a different one. As input
> modules are declared in cocoon.xconf they are handled by the global
> ComponentManager instead of the current sitemap ComponentManager.
> Therefore it cannot access Matchers or Selectors since they are handled
> in a different scope. There was simply no other choice.

Now I rememeber why I prefer using Cocoon that writing parts of it ;-)

>>Hmmm, but what does the parameter matcher in this case do? 
>>I'm not keen 
>>on having matchers be passed a special parameter.
>>Can't we simply concatenate the two strings?
>>For example, if I have:
>>    path/to/page.html
>>and I called:
>>    {lm:gogogo}
>>then I can give the locator:
>>   "lm:gogogo|path/to/page.html"
>>In this way I can use standard matchers that can decide to 
>>match on the 
>>part before |, on the part after, or both.
> I'm not sure if I understand this correctly. 

Basically it's about adding the inputmodule part to the request URI.

In this way I can not only take the inputmodule hint as a parameter, but 
as part of the "locator" requsest URI:

  locator request URI = locator hint + request URI

> Let me think this over.
>>>                                          -- o --
>>>In the first example a sitemap would be able to do something like:
>>><map:match pattern="**.html">
>>>  <map:generate src="xdocs/{1}.xml" />
>>>  <map:transform src="{lm:}" type="xslt" />
>>>  <map:serialize type="html" />
>>>Note the usage of the locationmap module: {lm:}. The input module 
>>>argument is empty because it is not used in the locationmap anyway
>>>(the matcher used is of type request).
>>If you do the above concatenation, I eould do:
>>    <map:transform src="{lm:style}" type="xslt" />
>>Which tells the locationmap to get me the url of the 
>>stylesheet for the 
>>current url.
>>I could then easily do:
>>    <map:generate src="{lm:source}" />
>>and have a nice differentiation.
> 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>
> </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.

>>Cool, so you are using the locationmap to drive link rewriting. 
>>Interesting :-)
> Yes, the current modules don't cover complete control over link rewriting.
>>> the test string that is passed to the selector in a locationmap
>>> has a more specific meaning than the test strings that are passed
>>> to it in the sitemap. In the locationmap's case it is the
>>> resolved location src attribute, whereas in a sitemap it can be
>>> anything because it is explicitly passed in as <map:when
>>> test="{something}"/>. some selectors do not make sense in the
>>> context of a locationmap (f.e. a HostSelector).
>>Hmmm... in any case, if it will be needed, we can still pass it in by 
>>adding a src attribute to each location.
>>        <select type="xxx">
>>          <location test="blah" src="file://unico/styles/{1}.xsl" />
>>        ...
> A type attribute which then overides the src attribute. I.e. if the
> test attribute is missing it will default to the source attribute. I
> like it.
>>>Things to do:
>> > - reconsider 'locationmap' naming (see above)
>>In what sense? "locationmap" seems fine for me in any case.
> In the sense that it is a mapping from request to string literal. The
> location mapping is one application of it. OTOH locationmap sounds cool
> enough ;)


>> Since yesterday I have started banging my head with 
>> and such, I'd like to start testing this on
>> Forrest and seeing as things go on how it works.
>>There is a problem though: AFAIK you are not a committer, and 
>>I cannot 
>>really accept such a donation... (see next mail)
> :-D

I'll start testing it ASAP, so I can tell you the first impressions.

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

View raw message