forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ferdinand Soethe <ferdin...@apache.org>
Subject Re: Gathering info on location maps
Date Tue, 09 May 2006 05:32:18 GMT

Thanks for putting more time into this.
I'm finally gaining some understanding, that was very helpful.

Ross Gardler wrote:

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

a good reminder to be more precise in my questions when I want an
equally precise answer. Sometimes I simply assume that I can save time
because people will understand what's in my head ...

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

Well it actually is just an example. But I like to think of very
specific examples to test my theorie of how it works ...

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

OK, this is one all important answer since it helps me understand the
mechanism. Not important if this is the best way.

But it gives me another interesting example to track and certainly it
doesn't hurt to

> 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

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


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

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.

> That's it, now an image with a src of "skin/images/[somedir]/logo.gif"
> will be looked for in your project defined location.

OK, theory here is understood, now I only need to see how Forrest
makes the connection between between "skin/images/[somedir]/logo.gif"
and <match pattern="skin.images.**.*">

> If it is not founf
> there it will fall back to the usual locations defined by forrest (see
> locationmap-skins.xml).

Understood.

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

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?

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.

--
Ferdinand Soethe


Mime
View raw message