cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brett McLaughlin <bmcla...@algx.net>
Subject Re: Sitemap and Links...
Date Fri, 31 Dec 1999 04:06:18 GMT


Pierpaolo Fumagalli wrote:
> 
> 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>

How about a more organizational format for the map:

<sitemap>
  <!-- Slight twist on the conventional way -->
  <prefix uri="flowers">
    <process uri="*.html" translate="/home/xml/*.xml">
      <producer name="file" />
      <processor name="xslt">
        <param name="stylesheet" value="flowers.xsl" />
      </processor>
      <serializer name="html" />
    </process>
   
    <process uri="xsp/*.html" translate="/home/xml/*.xsp">
      <producer name="xsp" />
      <processor name="xslt"> 
        <param name="stylesheet" value="flowers.xsl" />
      </processor>
      <serializer name="html" />
    </process>
  </prefix>

  <!-- More flexibility - assign processors to the prefix -->
  <prefix uri="diamonds">
    <processor name="xslt">
      <param name="stylesheet" value="diamonds.xsl" />
    </processor>

    <process uri="diamonds/*.html" translate="/home/xml/*.xml">
      <producer name="file" />
    </process>

    <process uri="diamonds/xsp/*.html" translate="/home/xml/*.xsp">
      <producer name="xsp" />
    </process>

    <serializer name="html" />
  </prefix>
</sitemap>

This to me makes more sense.  It allows several things:

(1) The problem you refer to goes away, as the prefix currently invoked
is searched before resorting to searching outer prefixes.
(2) Prefixes could be nested, to allow even further "heirarchical"
relationships
(3) Common prefix elements (serizlier and processor in the example file)
can be pulled out, reducing redundancy
(4) The extension proposal we have been mulling over fits in, as
processes can override prefix settings (so a given process whose prefix
specifies a processor may override that processor for the specific
process [tongue twister ;-)])
(5) You gain a "context" type feel without the added verbosity or
needing additional attributes - you only add one element, no attributes,
and reduce verbosity that is useless.

What do you think?

-Brett

> 
> 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