cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pierpaolo Fumagalli <p...@apache.org>
Subject Sitemap and Links...
Date Wed, 29 Dec 1999 17:49:45 GMT
Let's start with an example: we have a web server called "www.foo.bar"
and on that web server Cocoon handles all requests under the "/cocoon"
uri path.

We have this sitemap:

<sitemap>
  <process uri="*.html" translate="/home/www/sources/*.xml">
    <producer name="file"/>
    <filter name="xslt">
      <param name="stylesheet" value="/home/www/doc2html.xsl"/>
    </filter>
    <serializer name="html"/>
  </process>

  <read uri="graphic/*.jpg" translate="/home/www/images/*.jpg"/>
</sitemap>

In /home/www/sources/ we have two files (doc-1.xml and doc-2.xml) and in
/home/www/images/ we have one image (picture.jpg).

This sitemap tells that:
for this http request                    the "source" is
http://www.foo.bar/cocoon/doc-1.html     /home/www/sources/doc-1.xml
http://www.foo.bar/cocoon/doc-2.html     /home/www/sources/doc-2.xml
http://www.foo.bar/cocoon/picture.jpg    /home/www/images/picture.jpg

Let's start with doc-1.xml:

<document title="document 1">
  <paragraph>
    I like this document but <link href="doc-2.xml">this</link>
    is even nicer.
  </paragraph>
</document>

When this document is translated into html, it should become:

<html>
  <head>
    <title>document 1</title>
  </head>
  <body>
    <p>
      I like this document but <a href="doc-2.html">this</a>
      is even nicer.
    </p>
  </body>
</html>

If you note the difference between the source and the document, you'll
see that in the XML the link points to "doc-2.xml" and in the generated
HTML it'll point to "doc-2.html". So, the "link" has been translated,
but how? It can be translated embedding the rules into the XSLT
stylesheet, but this would create some problems because, when changing
the sitemap, we would also have to change the rules in the stylesheet
(in two places, so).

But Cocoon already has some rules to perform this translation
automatically. We would then need to embed an address translation engine
directly in there, deriving configuration from the sitemap.

To allow this, we can use namespaces: Let's imagine that
 <link href="doc-2.xml">
gets translated by our stylesheet in
 <a href="doc-2.xml" cocoon:translate="href">

Using our translation engine, cocoon might do the following:
It notices that <a> has an attribute specific to himself, since the
namespace is cocoon, and that attribute is translate. This rule tells
cocoon that another attribute, called "href" is an address that needs to
be translated, so it proceeds in this way:

The source url of the document is "/home/www/sources/doc-1.xml"
The link to be translated is "doc-2.xml", so, specifying its full path,
it becomes "/home/www/sources/doc-2.xml".

Then it looks inside the sitemap, and finds out which one of the
"translate" attributes of "process", "copy" or "redirect" elements
matches with "/home/www/sources/doc-2.xml"

It finds then a rule wich says that "/home/www/sources/*.xml" must
become "*.html", and so, it translates "/home/www/sources/doc-2.xml"
into "doc-2.html".

It changes the "href" attribute value in <a> and removes the
"cocoon:translate" attribute (to prevent further processing", and to the
formatter, the elements is forwarded as:
  <a href="doc-2.html">
Wich is exactly what we wanted to have.

Another example: /home/www/sources/doc-2.xml contains:

<document title="Document with an Image">
  <paragraph>
    This is the much nicer document because it contains this image.
    <image source="../images/picture.jpg"/>
  </paragraph>
</document>

>From the sitemap, we know that "/home/www/images/*.jpg" will be
"mounted" (can be requested) accessing
"(http://www.foo.bar/cocoon/)graphic/*.jpg"

So, what do we need to do? The stylesheet converts doc-2.xml into:

<html>
  <head>
    <title>Document with an Image</title>
  </head>
  <body>
    <p>
      This is the much nicer document because it contains this image.
      <img src="../images/picture.jpg" cocoon:translate="src"/>
    </p>
  </body>
</html>

The "translating engine" sees that <img> contains the attribute
"cocoon:translate" and so that it needs to translate the "src"
attribute; so:
1) gets the source document uri: /home/www/sources/doc-2.xml"
2) finds that ../images/picture.jpg, relative to it, becomes
   /home/www/images/picture.jpg
3) checks the sitemap for the appropriate "translate" attribute and
   finds that "/home/www/images/*.jpg" becomes "graphic/*.jpg"
4) rewrites the "src" attribute to "graphic/picture.jpg" and removes
   cocoon:translate
5) forwards the document to the serializer (next in the process chain)

So, at the end, the client will see the document as:

<html>
  <head>
    <title>Document with an Image</title>
  </head>
  <body>
    <p>
      This is the much nicer document because it contains this image.
      <img src="graphic/picture.jpg"/>
    </p>
  </body>
</html>

Wich is exactly what we wanted to achieve...

Note: I don't like the "cocoon:" namespace, I would prefer this into the
xlink namespace, because that's the correct place (see the XLINK spec),
but currently the spec is thought only for client side, and completely
ignores the server side. Maybe we can have this feature added in the
spec, wich is (IMVHO) really important when thinking about server side
processing of XML.

I hope I was clear enough... and please, as always, please try to
destroy this with all your intelligence, because I'm sure that more
people think about it, the better it'll become.

	Pier :) :) :)


Mime
View raw message