forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <rgard...@apache.org>
Subject Re: Gathering info on location maps
Date Mon, 08 May 2006 19:21:59 GMT
Ferdinand Soethe wrote:
> 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.

Yeah, sorry. The reason I snipped your specific questions is because 
they gave an either/or option which, in general were wrong. I thought I 
detected a basic misunderstanding of how things work, and was trying to 
remove that first. I tried to replace your examples with ones that were 
a little more focussed on the two distinct uses of the LM.

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

You can try other examples too, if you like (which you have)...

> Ross Gardler wrote:
...

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

Now having a clear description of the use case helps a great deal, 
previously you just asked about an image on tabs. I didn't realise this 
was a concrete example of a specific use case, I just thought you were 
asking about the pricessing of images as an example of the way the 
locationmap works. After all, the subject is that general.

Now I understand your specific motivation, lets try again...

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

That is one way, and it would work, but this can be done much more 
easily, and already is possible since skin images are already processed 
separately from content images by the LM:

<map:match pattern="skin/images**/*.*">
   <map:read src="{lm:skin.images.{1}/{2}.{3}}" mime-type="image/{3}" />
</map:match>

So all you need to do is add a conditional match to your project LM. 
Something like:

<match pattern="skin.images.**.*">
   <select>
     <location src="{project:content}/images/{1}.{2}" />
   </select>
</match>

That's it, now an image with a src of "skin/images/[somedir]/logo.gif" 
will be looked for in your project defined location. If it is not founf 
there it will fall back to the usual locations defined by forrest (see 
locationmap-skins.xml).

The results are almost the same. The key difference is that the URL the 
client sees is not rewritten, which is a good thing as it means you can 
change the location of the resource without breaking external links to 
the resource.

Am I missing the point?

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

Sorry, I can't parse that. Your quoted sentence above looks fine though, 
so I guess it's right.

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

Correct....

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

Yes, more flexible, easier to read, look at the resources.xmap in head 
compared to resources.xmap in 0.7 for example, easier to override for 
specific resources.

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

Yes, but consider my comments above.

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

I won't restate it is possible, but I will ask what it gives you that 
the current situation does not give you?

Ross

Mime
View raw message