Ferdinand Soethe wrote:
Ross Gardler wrote:
- java code that calculates the final url or
Java code:
http://svn.apache.org/viewcvs.cgi/forrest/trunk/main/java/org/apache/forrest/locationmap/
OK, thanks. I found that. But where is it tied into cocoon? In other
words, how/where does Cocoon learn to process lm: this way?
This is not important from the point of view of Forrest docs. Take a
look at InputModules in Cocoon docs.
Within forrest the LM is defined in the forrest-core.xconf
...
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.
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:
<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"
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.
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.
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>
Does that mean it is going to replace site? Or ext:?
This functionality is now duplicated. Will lm: replace site: and ext:? I
think it should certainly replace the usage of "ext:", which should be
deprecated. It is a much tidier way of doing this, and keeps all
location information in a single file - got to be a good thing. It also
means other navigation documents that do not support the ext notation
can use rewriting like this.
I'm not so convinced about the "site:" protocol though. I don't use it
so do not fully understand the use cases in which it would be used. I
don't use it because it is clumsy and difficult to maintain, i.e. move
something in the menu structure and site: links are broken. Certainly I
cannot think of any usage of "site:" that I cannot us "lm:" for.
Perhaps when the LM is better documented and we have resolved the
rewrite issue we can discuss deprectaing one or both of ext: and site:.
Ross
