forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <>
Subject Re: Gathering info on location maps
Date Mon, 08 May 2006 13:45:24 GMT
Ferdinand Soethe wrote:
> Ross Gardler wrote:
>>>   - java code that calculates the final url or
>>Java code:
> OK, thanks. I found that. But where is it tied into cocoon? In other
> words, how/where does Cocoon learn to process lm: this way?

This is not important from the point of view of Forrest docs. Take a 
look at InputModules in Cocoon docs.

Within forrest the LM is defined in the forrest-core.xconf


> To me this reads like:
> 1. If I used a url like [someDir]/logo.gif lms are not referred to at all. So
>    either there is logo.gif in that directory or I get a link error.

Do not get confused between the client URL and the internal URL used by 
Forrest. The client URL is what the user sees in their browser, the 
internal URL is what Forrest uses to retrieve the data.

The LM is used in two roles:

1 - a central location for client URLs (much like the ext: protocol)
2- an internal translation engine between client URLs and data URLs

The above URL ([someDir]/logo.gif) is a client URL. It is what the user 
sees if they do "view source". In Forrest client URLs are processed by 
the sitemap. So, if you read the sitemap you will see something like:

<map:match pattern="**/**.gif">
   <map:generate src="{lm:project.images.gif.{1}}"/>

In other words, the client URL you give is transformed into an internal 
URL by the locationmap. What the client sees will remain 

Why do this?

It means we can change the internal location of all images, all gifs or 
a single image by editing the locationmap definition. Changing this will 
not break the existing URL space that the user sees.

> 2. If I use lm:[someDir]/logo.gif instead it all depends on the
>    locationmaps involved.

(NOTE: the correct syntax is lm://[someDir]/logo.gif because this is a 
client URL not a cariable reference in the sitemap, which would use 
"lm:" - without the "//")

Here you are defining a client URL that uses the locationmap. This will 
result in the client URL being rewritten according to the locationmap 
rules you have set. What the client sees is the resolved match for 
"[someDir]/logo.gif" in your locationmap.

NOTE - there is currently an unexplored issue that results in the 
fresh-site example of this being broken.

Why do this? It allows us to change client URLs without having to edit 
every location they are referred to, for example:

<a href="lm:myHomePage">Homepage</a>

> Does that mean it is going to replace site? Or ext:?

This functionality is now duplicated. Will lm: replace site: and ext:? I 
think it should certainly replace the usage of "ext:", which should be 
deprecated. It is a much tidier way of doing this, and keeps all 
location information in a single file - got to be a good thing. It also 
means other navigation documents that do not support the ext notation 
can use rewriting like this.

I'm not so convinced about the "site:" protocol though. I don't use it 
so do not fully understand the use cases in which it would be used. I 
don't use it because it is clumsy and difficult to maintain, i.e. move 
something in the menu structure and site: links are broken. Certainly I 
cannot think of any usage of "site:" that I cannot us "lm:" for.

Perhaps when the LM is better documented and we have resolved the 
rewrite issue we can discuss deprectaing one or both of ext: and site:.


View raw message