cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jonathan Stimmel <>
Subject Re: Squaring the sitemap circle...
Date Thu, 08 Jun 2000 19:46:51 GMT
On Fri, May 26, 2000 at 05:38:06PM +0200, Stefano Mazzocchi wrote:

> An improved version of the sitemap has been just placed on the CVS
> cocoon2 branch. I will refert to that one from now on.

Interesting... I like. Comments on specific pieces follow (and bear
in mind that I view cocoon from a live-server standpoint; I have
less interest in the offline mode, so my views are admitedly biased).

> 7) uri mapping should be powerful enough to allow every possible
> mapping need

Nit-pick: I think this wording is dangerous. I think it's more
important to handle "most common" needs well, get it out the door,
and learn from how people are actually using it. (Hmmmm... after
a little more thought, I think I misinterpreted your intentions; by
allowing people to create their own matchers, this requirement
has already been met!)

> The main matching type, URI matching, is hardcoded into the sitemap
> schema because, by far, [it is] the most used

URI matching is almost certainly going to be part of every pipeline,
but I'm not convinced it should be treated as a special case. The models
I've seen thus far force the use of the URI as the primary matching
agent. What if I want to organise my sitemap by output format (e.g.
HTML vs. WAP)?

> Mount points allow sitemaps to be cascaded and site management workload
> to be parallelized.

> <mount
>    uri="^/xerces-[j|c|p]/(.*)$"
>    src:cvs="$1/xdocs/$2"
>    rule="regexp"/>
> <mount
>    uri="faq/*"
>    src:jar="jar:./apps/faq-o-matic.cocoon#*"/>

I'm not sure I understand the purpose of the mount tag; to me it just
looks like another version of the <process>. From the description, I would
expect it to be more like mounting a filesystem (grafting a sitemap
onto our URI tree), more like:
  <mount uri="/faq" src="/faq/faq.xconf"/>

(BTW, there's a typo in your regex; "[j|c|p]" should be either "([jcp])"
or "(j|c|p)". Not that it really matters in a nonfunctional prototype... =)

> <redirect to="dist/cocoon/*"/>

Why such a specific tag? Perhaps something more generic is in order
(action? response?). A related action would be setting the return
code (not sure if this is a realistic example, just a first reaction).

You know, in some ways this is kind of like a specialized serializer;
both redirect and a true serializer send something to the client. Of
course, the redirect doesn't convert an XML tree into a stream, so
calling it a serializer would be a bit of a misnomer. I wonder if
perhaps we could extend the concept of a Serializer to include
this type of functionality. (I'm not sure I necessarily advocate
generalizing serializer, it's just a thought...)

** Proposed modifications

Currently, the sitemap is viewed as a collection of parts (the process
tags). What if we viewed it as a tree (after all, isn't that what
URIs and XML are?). The root of the tree would be a matcher (normally
matching against URI, but other organizations would be possible - e.g.,
my HTML vs. WAP example). Here's a quick example (the following would
follow the Component declarations):

<matcher type="uri">

  <!-- Simple rule to cover random xml files -->
  <match value="/*.xml">
    <generate type="file" src="/*.xml"/>
    <filter type="xslt">
      <param name="stylesheet" value="/*.xsl"/>

  <!-- Here's our company directory, which our salespeople need
       to access via their cell phones -->
  <match value="/directory">
    <generate type="sql" src="/directory.xml"/>
    <matcher type="browser">
        <filter type="xslt">
          <param name="stylesheet" value="/directory-html.xsl"/>
        <serialize type="html"/>
      <match value="Nokia">
        <filter type="xslt">
          <param name="stylesheet" value="/directory-wap.xsl"/>
        <serialize type="wap"/>

  <match value="/ourStuff/*">
    <!-- Who was the idiot who put our product info under this
         directory?! We should redirect them to the newly created
         /products/ directory -->
      <header name="Location" value="/products/*">

  <match value="/products">
    <sitemap src="/products/sitemap.xconf"/>

    <generate type="file" src="/errors/notfound.xml"/>
    <filter type="xslt">
      <param name="stylesheet" value="/errors/notfound.xsl"/>
      <header name="Status" value="404 Not Found">
      <serialize type="html"/>


I can see some problems (what if you want an actual "*" in a
response header?), but I think it gets my intentions across.
Please comment =)

View raw message