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
