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 Tue, 09 May 2006 07:53:51 GMT
Ferdinand Soethe wrote:
>>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}" />
> OK, I understand where you are aiming, but in practical terms
> you are loosing my again. A ft-search did not reveal any
> mention of this pattern. I only found this

This is in resource.xmap. You can see it is an xmap because of the 
syntax used, in particular map:* and the use of <map:read ...>. Of 
course, one can only see this if one knows the syntax of both the xmap 
and locationmap languages.

Another way to figure out what you are looking at is think about what 
the snippet is doing. Recall that client URLs (such as 
"skin/images/foo/bar.gif") are processed by the xmap first, which says, 
"look it up in the LM", which leads us to :

> <match pattern="skin.images.**.*">
>   <select>
>     <location src="{project:skins-dir}{forrest:skin}/images/{1}.{2}" />
>     <location src="{forrest:context}/skins/{forrest:skin}/images/{1}.{2}" />
>     <location src="{forrest:context}/skins/common/images/{1}.{2}" />
>   </select>
> </match>
> in locationnmap-skins.xml.
> And I can't make the connection since I also couldn't find any mention
> of skin.images.
> I also looked at pelt-skins site-to-xml.xsl which doesn't use any
> lm:-pseudoprotocoll to tie in the images.
> So where am I going wrong?

It's back to client URLs and internal URLs again. If we use the LM in a 
client URL then it would appear in places like site-to-xml.xsl. As we 
have seen such a usage will be rewritten to a differnt client URL.

However, what the above does is use the LM to resolve an internal URL. 
So we use the xmap to convert from the client URL to the internal URL, 
which is transformed by the LM in the above sitemap 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>
> So in fact I'm overriding the pattern in the above mentioned lm with
> my own image location mechanism?


> But then, wouldn't I override it for all images needed for skinning,
> including icons for css etc? This may or may not be what I want.
> Anyhow I understand that in the end I could get tab specific
> menu-twisties as well.

Yes, but... because we use the <select> tag we are allowing the original 
match to come into play if the new one does not provide a resource. So 
addig the above does not break anything it simply provides an an 
additional *possible* location.

If we left out the <select> it would completely replace the original LM 
entry, thus would mean all resources would have to be in the new location.

This extending of locationmaps really needs to be documented in [1]

>>Am I missing the point?
> No. But let me get take this a bit further:
> Since the URL that the client sees is (must be) also the url where
> cocoon will create (copy to) the logo-image file, our two different
> solutions will have a very different effect.
> Give a structure like:
> xdocs
>   |  logo.gif (main logo)
>   |
>   +-tabdir1
>   |     logo.gif (tab spec logo for tab 1)
>   +-tabdir2
>   |     (NO tab spec logo for tab 2)
>   +-tabdir3
>   |     logo.gif  (tab spec logo for tab 3)
>   +-tabdir4
>   |     (NO tab spec logo for tab 4)
> - my solution (re-written url) means that
>   in pages in tabs 1 and 3 the url to logo.gif is re-written to point
>   to the local logo-file whereas the url in tabs 2 and 4 will point to
>   the central logo file.
>   As a result all logo files will only exist once in the resulting
>   static site just as they do in xdocs.
> - now looking at your solution (if I get that right) I understand that
>   it leaves the original url intact, which makes not difference for
>   tabs 1 and 3 (that have local logos) but would make a difference for
>   tabs 2 and 4 (that have no logos) because in order to not change the
>   url it is (in simple terms) putting the data where the url points
>   to, effectively re-creating the central logo file in tabs 2 and 4
>   thus duplication it for every location.
>   Right?

No, that is not right. The client will see whatever URL is encoded in 
the source documents. So, "skin/images/mytab.gif" will be placed in 
"skin/images/mytab.gif" regardless of where it comes from. We are 
rewriting the internal URL not the client URL.

We only end up with a duplicated resource if the page sources use two 
different URLs to point to the same resource. If we use the same URL 
(i.e. "skin/images/mytab.gif") that is what the client sees and 
therefore there is only a single version of the resource

This is a good thing since two URLs imply two different uses. In the 
second approach we can change one of the two resources and not break the 
client URLspace, which cannot be done in the first approach. For 
example, we could make a locationmap that always returns a "No image 
found" image if an image cannot be resolved. Then, when we add an image 
into one of the locations where it is allowed to live it will start 
appearing. In this instance we have a development system up and running 
quickly and the resource will appear when the graphic designers have 
completed it - no need for additional editing of the sources.

> If that is so, I'd actually prefer my solution because yours will
> increase the size of my site and undermine image caching by the
> browser.

I still think you are confusing client urls using the lm: protocal 
(which will get rewritten on the client side) and internal URLs using 
the locationamp (which will not get rewritten on the client side).



View raw message