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 Mon, 08 May 2006 12:59:07 GMT






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


Mime
View raw message