cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Giacomo Pati <>
Subject Sitemap mount concerns
Date Tue, 18 Jul 2000 14:42:58 GMT
Hi all

Sorry to bother you with thought's about the sitemap implementation
stuff we discussed during the last weekend at the Cocoon Hackaton #1 in
Pavia. But I thought it can be interesting to others.

As I left from Pavia, almost everything seems to be clear for the
sitemap implementation. But as always details covers some unpredictable
exceptions. Today I've coverd the following case. Given the sitemap

   <map:match pattern="dist/*">
    <map:mount src="./dist/{1}"/>

This means that there must be a sitemap located at
"./dist/ANYDIR/sitemap.xmap". Unforunately the "./dist/{1}" cannot be
resolved at startup time because pattern matching takes place at run
time (only the path to the root sitemap is known at cocoon startup
time). Behind the snipped above there could be hundreds of different
sitemaps. So we have two possibilities.

1. Make sub sitemap generation/compilation/instantiation/initialisation
   at run time.
2. Make a separate <map:mounts> section restricting the src= attribute
   values to a fixed path and add an additional uri-prefix= attribute 
   which specifies what its name implies (prefix of the uri the sub 
   sitemap is mapped to).

Consequences of
1. If the sitemap encounters a <map:mount> for the first time and thus
   has no "old" sub sitemap to use during asynchronious sitemap
   generation, it has to report an "unavailable error" to requestors or
   do the generation of the sitemap synchroniously and delay the
   until generation is finished. In every other case even if the
   has changed there is still an old sitemap object to use until the 
   generation of the changed sitemap is ready to take control.
2. This approach is less flexible but would garantee to have a 
   responsive system after startup because all sitemaps could be 
   generated at startup time. Requests to a starting cocoon system
   be automatically queued by the servlet engine. 

The notation of a uri-prefix itself would also solve the problem of
telling the Environment object at which "current directory" in the uri
space it is when chaining to sub sitemaps (remember we said that sub
sitemaps have no notion of where in the uri space they are mounted on
from the view of a sitemap maintainer). Otherwise the <map:mount>
element has to deal with the request.getUri() and the match of a
possibly not available uri-matcher to find out the prefix to advance in
the uri space for a sub sitemap. Because the mount element is an
internal component of the sitemap as apposed to the sitemap components
like generators, serializers, etc, this has the benefit that the mount
element doesn't have to deal with environment specific things like
'environment.getRequest().getUri()'. This would eliminate another
contract to the calling environment. <map:mount> only has to tell the
Environment that from now on it has to advance to the uri-prefix
position in the uri space for subsequent requests of components to the
uri in sub sitemaps.

And at the end I will suggest to move the sitemap internal <map:read>
element to a <map:readers> section in the sitemap components (located
in package org.apache.cocoon.reading :) to eliminate the (I think) last
contract of the sitemap to the Environment. Remember a <map:read>
implements a serializing generator. This will open the possibility to
provide specific readers for specific needs. With this last change the
sitemap is free from dealing with environment specific things except
that the Environment object has to offer a method to set the "current
directory" for the <map:mount> element.

Please help and comment this.


PWR GmbH, Organisation & Entwicklung      Tel:   +41 (0)1 856 2202
Giacomo Pati, CTO/CEO                     Fax:   +41 (0)1 856 2201
Hintereichenstrasse 7           
CH-8166 Niederweningen                    Web:

Do You Yahoo!?
Get Yahoo! Mail  Free email you can access from anywhere!

View raw message