cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <>
Subject [C2] Sitemap Mounting issue
Date Thu, 19 Apr 2001 13:29:15 GMT
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.

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.

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

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 have successfully decoupled cocoon.xconf from needing to be in the
same place the root sitemap is--but I only had one area to change.
The sitemap (depending on complexity) can have hundreds of paths to

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

View raw message