cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pierpaolo Fumagalli <p...@apache.org>
Subject Re: Sitemap and Links...
Date Fri, 31 Dec 1999 03:46:24 GMT
Let's keep this....

> > <sitemap>
> >   <process uri="flowers/*.html" translate="/home/xml/*.xml">
> >     <producer name="file"/>
> >     <processor name="xslt">
> >       <param name="stylesheet" value="flowers.xsl"/>
> >     <processor>
> >     <serializer name="html"/>
> >
> >   <process uri="diamonds/*.html" translate="/home/xml/*.xml">
> >     <producer name="file"/>
> >     <processor name="xslt">
> >       <param name="stylesheet" value="diamonds.xsl"/>
> >     <processor>
> >     <serializer name="html"/>
> >
> >   <process uri="flowers/xsp/*.html" translate="/home/xml/*.xsp">
> >     <producer name="xsp"/>
> >     <processor name="xslt">
> >       <param name="stylesheet" value="flowers.xsl"/>
> >     <processor>
> >     <serializer name="html"/>
> >
> >   <process uri="diamonds/xsp/*.html" translate="/home/xml/*.xsp">
> >     <producer name="xsp"/>
> >     <processor name="xslt">
> >       <param name="stylesheet" value="diamonds.xsl"/>
> >     <processor>
> >     <serializer name="html"/>
> > </sitemap>

Brett McLaughlin wrote:
> [...] I must misunderstand you here.
> [...] Or am I missing the point entirely?

My fault... The example wasn't explained well enough. Let's keep the
same sidemap (to ease a little bit I placed "/home/xml" in the
"translate" attributes:

I have two files in "/home/xml":
- one is called "test.xsp"
- the other is called "doc.xml".
To style them, I use two stylesheets, one is "flowers.xsl" and one is
"diamonds.xsl".

Let's test the sitemap, then (our host is www.foo.bar and cocoon is
handling all request starting with the "cocoon" path).

When a request for "http://www.foo.bar/cocoon/flowers/doc.html", Cocoon
reads "/home/xml/doc.xml", applies "flowers.xsl" and serializes it to
the client using the HTML writer. In the same way when
"http://www.foo.bar/cocoon/diamonds/doc.html" is requested, Cocoon reads
"/home/xml/doc.xml", applies "diamonds.xsl" and serializes it to the
client.

When, instead, a request for
"http://www.foo.bar/cocoon/flowers/xsp/test.html" or
"http://www.foo.bar/cocoon/diamonds/xsp/test.html" is made, the source
"/home/xml/test.xsp" is loaded and executed (it's an XSP :), and again,
depending on the uri, one of the two stylesheets is applied, and then
serialized.

Let's assume that "/home/xml/test.xsp" contains this link:
  <link href="./doc.xml">a link</link>
The link, seen from the source point of view, is correct, since it
points to "/home/xml/doc.xml" wich is existent, and served as
"http://www.foo.bar/cocoon/[flowers-or-diamonds]/doc.html".
Cocoon, so, should "rewrite" this link to point to the correct one:
depending on how the XSP was requested, the link must be updated to
point to the correct "flowers" or "diamonds" version.

The rule says: "first look in your area, if you find that, convert it,
otherwise start from the first area in the sitemap and try to
translate".

Cocoon takes "./doc.xml", relative to "/home/xml/test.xsp", understands
that the target of the link in the source file is, so,
"/home/xml/doc.xml".

Let's say that the XSP was requested thru
"http://www.foo.bar/cocoon/flowers/xsp/test.html", so, it tries to see
if the link is inside the THIRD area. It is not, since the third area
matches only "/home/xml/*.xsp", so it starts analyzing the first area.

Here it finds a match, because the first area matches "/home/xml/*.xml",
so, it "translates" the link as it was defined there, and produces
"http://www.foo.bar/cocoon/flowersdoc.html".

In this case it was correct, BUT, if the XSP was requested thru
"http://www.foo.bar/cocoon/diamonds/xsp/test.html" (fourth area), we
would like to have the rewritten link to point to
"http://www.foo.bar/cocoon/diamonds/doc.xml" (second area), while Cocoon
translates it again as it was in the first one
"http://www.foo.bar/cocoon/flowers/xsp/test.html" (see the rule), wich
is not correct.

This happens because it doesn't know that the first area is in relation
with the third, and the second with the fourth.

The only "solution" I came up with, was to give to areas a
"linking-context", so that links can be resolved successfully (saying
for example, that area 1 and area 3 have a context called "flowers" and
2 and 4 another called "diamonds"), but, as I said, adds verbosity and
complexity to the sitemap. And that's a thing I wanted to avoid.

I hope it's a little bit clearer, now.
Now, same request... Please HELP :) :) :)

    Pier (at 4:45AM still thinking about it, better get some sleep)

Mime
View raw message