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}" />
</map:match>
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>
</match>
So in fact I'm overriding the pattern in the above mentioned lm with
my own image location mechanism?
Yes.
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).
Ross
[1] http://forrest.apache.org/docs_0_80/locationmap.html
