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?
>> b) Where does this processing take place?
>>
>> - Everywhere linkrewriter is called?
> Yes, whenever the psuedo prototocl of "lm:" is used.
So is lm called from linkrewriter?
>> c) What are the standard processing steps for
>>
>> - a normal url
> If no variables present, i.e. src="/foo/bar.html"/> Used by the
> generator or reader to directly retrieve the document from the indicated
> locaton (relative to the sitemap).
> If a variable is present, ie. src="{project.xdocs}/foob/bar". The
> variable is substituted by a Cocoon InputModule and the sorce is
> retrieved from the resulting location.
>> - a url in site.xml
> The URL is retrieved by the Cocoon crawler and processed as in a) above
Wait a second.
The crawler crawls the the final url-space starting
from index.html and crawling all the local links it can find.
That means that a url in site.xml has already been transformed a
number of times before it becomes part of the final crawled page,
right?
So it can't be that easy, can it?
>> - a site:-url
>> - an ext:-url
> These are processed by an Input Module (just like the locationmap one).
> The pseudo protocol is used to find the real URL of the "site:" url and
> then it is processed as in a) above.
>> 2. Docs state that
>>
>> > Apache Forrest looks in the standard location for the source file
>> > first (by default PROJECT_HOME/src/documentation/content/...), if a
>> > file is found in this location then the locationmap is not
>> > consulted.
>>
>> This is a great feature!
> This is not the case any more. We did it like this in the original
> enabvlement of the LM as it gave a guarentee existing sites would not
> break. However, the locationmap is always consulted now. This enables
> users to override the default behaviour.
> Default behaviour is still to look in the default location first, but
> this may be changed by a project.
>> a) Is it correct to say that lms are evaluated whenever a normal
>> URL such as "/blabla.html" cannot be resolved? Even when the
>> URL does not begin with lm:?
> No - LMs are only involved if the psudeo protocol is present.
>> b) How do sitemap cascades (such as looking up an image file in
>> different places) coexist with locationmaps? Will lm only be
>> evaluated when _all_ other matchers have failed?
Hmmm, to get this strait.
Is it correct to say that
1. locationmapping only happens
a) when a url is processed in linkrewriter? and
b) uses the lm: pseudoprotocol?
2. So a normal url is not ever processed by lm (unless sitemaps involve
lms internally)?
So when lms are involved, does
> Default behaviour is still to look in the default location first, but
> this may be changed by a project.
mean that processing something like 'lm:/index.html' looks like this:
- A lookup in the locationmap always happens
-- when there is no match for /index.html and there is a file
/index.html it is returned.
-- when there is a match in the locationmap, it is processed
and returned instead if the original file.
> All resolving of resources is now done the the locationmap. If you take
> a look at resources.xmap you will see that there are no longer
> alternative locations, only alternative source file formats (i.e. jpg.
> svg, gif etc.).
So why are there still
<map:match pattern="images/**.*">
and
<map:match pattern="**/images/**.*">
> Now take a look at the locationmaop-resource.xml file
> and you'll see that all the alternative locations are moved to there.
Couldn't find that file even after correcing the type to
locationmap-resource.xml.
>> c) Is it correct to assume that using the lm:-prefix on a URL will
>> skip the step of looking for the standard file location?
>> Or else what would the standard location on named files be?
> See a) above. In summary, it is correct to assume this if the user has
> not overridden the locationmap entry for that resource type.
Will wait for answers to the above before I ask more.
>> d) So if I wanted to implement tab-specific logos in our skin
>> - I just point to a file like logo.gif in the tabs base directory
>> - and create a locationmap with a pattern that would resolve all
>> those references to a central (main) logo
>> and, as a result, would see the local local if there is such a
>> file or the main logo if there was none?
> Again, see a) and c) - same answer again.
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.
2. If I use lm:[someDir]/logo.gif instead it all depends on the
locationmaps involved.
a) if I have not changed anything the default search cascade (now
implemented in a lm kicks in and a will get something like
- [someDir]/logo.gif
- [someDir]/logo.gif in resources/images
- logo.gif anywhere in resources/images (if the old Forrest
behaviour is still in place)
b) if I created my own litte matcher in the project locationmap I
could change this to try and find logo.gif first in a local
directory, then in a master directory of my choice.
> Note, you would not need to create a locationmap entry unless you wanted
> to put the images in a non-standard location. just ensure you use the
> naming convention, i.e. "lm:project.images.myTabImage"
So this is for creating my own locationmap, right?
I'm supposed to use a named handle rather then a filenname, correct?
If so, how do I the pass a variable part like [someDir] to this
matcher? Is this
<match pattern="project.images.**.*">
such an example with 'project.images.' being a named handle and
.**.* being a variable part?
So my handle could look something like <match
pattern="project.images.myTabImage.**.gif"> with urls in skinning
looking something like 'project.images.myTabImage./tabA.gif'?
>> 3. When it says
>>
>>
>>>The locationmap can be used to rewrite URLs when the page is
>>>generated. For example, when the locationmap has:
>>>
>>> <match pattern="rewriteDemo/**">
>>> <location src="http://www.domain.org/{1}.xml"; />
>>> </match>
>>>
>>>
>>>With the above match in the locationmap, a link which has
>>>href="lm:rewriteDemo/index" will be rewritten to an offsite address
>>>at domain.org
>>
>>
>> Is it correct to say that the user will see an address of
>> mysite/rewrite/blablub.hmtl while the content was retrieved from
>> http://www.domain.org/blablub.xml?
> No, this is a rewrite. The user will see the new URL. This is similar
> functionality to ext: and site: In fact it is a duplicateion of ext: and
> a much more efficient way of managing such things (in my opinion) since
> it means you can have rewrites in content objects that do not have a
> site.xml schema that can define rewrite rules (like Daisy or IMS
> manifests for example).
OK, so when I use 'mysite/rewrite/blablub.hmtl', the final static
pages will contain 'http://www.domain.org/blablub.xml'.
> This is similar
> functionality to ext: and site:
Does that mean it is going to replace site? Or ext:?
Thanks,
--
Ferdinand Soethe
