forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ferdinand Soethe <>
Subject Re: Gathering info on location maps
Date Mon, 08 May 2006 15:20:02 GMT

Thanks for taking the time. But I'm having a hard time following your
rather abstract explanations. That's why I wrote all these questions
and examples.

But since I'm at it, let me try and go with your response.

Ross Gardler wrote:

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

Thanks. It helps me understand what is going on.

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

I didn't think I was confusing this. But may be I am.
God, it is confusing ... I need to stick to practical examples to

So I was still looking at the question wether and how I could use lm to
create a rather flexible lookup for the logo-file in a skin.

Use case: Refer to a logo image file logo.gif in the skin in a way
          that it will automatically use logo.gif in a tabs base dir
          and fall back to a central logo.gif if there is none.

The way I see it this is one way to achieve this:

-  an abstract url I use in the skin could be rewritten (meaning
   replaced) by a concrete url that points to the logo.gif in the tabs
   base dir (if present) or to the central logo.gif somewhere else.

   In both cases the user would see this rewritten url when they do a
   view source of the final page.

   The flexibility would lie in the decision the locationmap is making
   when being resolved. If there is a logo.gif in the tab dir return
   that url, if not return the central one.


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

OK. I see where you are going. But doesn't it have to be more specific
then this and read "In Forrest _requests to_ client URLs are processed by
the sitemap."

Meaning that the client URL will remain the data to create the file
with this url will come from the pipeline below?

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

> In other words, the client URL you give is transformed into an internal
> URL by the locationmap. What the client sees will remain 
> "[someDir]/logo.gif"

OK. This used to be something we did with the sitemap without lms, now
we are using the additional abstraction layer of lms.
But in the end we are still re-routing the request to different data

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

Which is the same we did with the normal sitemaps before, only more
flexible with lm. Right.

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

Which is exactly what I needed for the above mentioned use case, isn't

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

I understand this use case. But I'm confused. Is my above mentioned
use case not possible then?

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

I agree. I always wondered what the use of site was. It seems like
going half way in making it independent of file location but
exchanging one dependency for another (menu location).

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


Ferdinand Soethe

View raw message