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
alter.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
|