cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From giacomo <>
Subject Re: [C2] Sitemap Mounting issue
Date Thu, 19 Apr 2001 19:28:25 GMT

On Thu, 19 Apr 2001, Berin Loritsch wrote:

> I recently made an attempt at using the mount sitemap feature.
> While I did get it working, there are some interesting "features"
> surrounding it's use.  It has to do with two aspects: Components
> and file paths.
> 1) Sitemap's must redeclare the defaults for transformation.
>    While it is beneficial to override the parent sitemap's
>    declarations--it would be better if we could use the
>    parent sitemap's defaults if possible.

Technically this is no problem we can additionally add the default
Component to the ComponentManager under a "well-known-name" by the
sitemaps. But we'll have it added twice. This I think is necessary
because all the references to components must be doable by the XSLT
stylesheet which generated the sitemap java code (sitemap.xsl)

> 2) All paths referenced in the sitemap are relative to the sitemap.
>    This is severely limitting and unintuitive for a couple of reasons.
>    a) You can't use the same stylesheets that the parent uses without
>       making a copy or using symbolic links.
>    b) Many people think in terms of context relative paths.  If I
>       specify the path "foo/bar.xml" I _naturally_ expect the file
>       to reside at $CONTEXT_DIR/foo/bar.xml.  In a mounted sitemap
>       it is relative to the sitemap file.
>    c) You can't hide the sitemap files inside the /WEB-INF directory
>       to take advantage of Servlet Container's protecting that directory
>       from prying eyes.

You have to reread the original proposal of the mount element where
constructs like the following should been allowed:

<map:match pattern="cocoon/*">
 <map:mount uri-prefix="cocoon/{1}" check-reload="yes"

<map:match pattern="bugs/*">
 <map:mount uri-prefix="bugs/{1}" check-reload="true"

As you can easily see there is not such "common" context among mounted

Another thought was that this way you can spread the sitemap power to
different groups having their own context and are not forced to know
such things like "root context". And each owner of a sitemap can
delegate URI sub space to other people. I still think this concept is
great. But it is possible that the current implementation is not able to
follow completely (URLFactory)

> So how do we solve this?  I hope I can present a sound way of accomplishing
> the goals.
> 1) We maintain the defaults outside the sitemap.  One component that
>    acts as a storage for the default values based on a "key" or
>    hash value assigned to the sitemap.  It takes care of the issues
>    surrounding if Sitemap X mounts Sitemap Y, then when Y asks for
>    a specific Generator it will provide the defaults in reverse order
>    of mounting (i.e. if Sitemap Y doesn't specify a default, then
>    use the one for Sitemap X).

See sugestion above.

> 2) Make all paths referenced in the Sitemap Context relative.  This
>    allows for using the same stylesheets no matter how many levels of
>    Sitemap mounts we do.  It will also allow us to take advantage of
>    most servlet containers' security over files.  Lastly, it is more
>    intuitive for new Cocoon developers.

I doubt the last sentence. Its like a chroot environment.


To unsubscribe, e-mail:
For additional commands, email:

View raw message