You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Berin Loritsch <bl...@apache.org> on 2001/04/19 15:29:15 UTC
[C2] Sitemap Mounting issue
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
AW: [C2] Sitemap Mounting issue
Posted by Carsten Ziegeler <cz...@sundn.de>.
> Giacomo Pati wrote:
> On Thu, 19 Apr 2001, Berin Loritsch wrote:
>
> > giacomo wrote:
> > >
> > > On Thu, 19 Apr 2001, Berin Loritsch wrote:
> > >
> >
> > <Snip/>
> >
> > > > 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.
> >
> > (maybe I should have qualified it to _servlet_ developers)
> >
> > You presented some convincing arguments regarding the way it is
> set up now.
> > There is still the redundancy issue with stylesheets. How do I use a
> > specific stylesheet without having 10 copies of them based on where the
> > map is mounted.
>
> I see I've never thought about them.
>
> > We have a series of stylesheets that all pages are sent through
> so that we
> > have a uniform look and feel. I am trying to keep the modularity up and
> > the rework down. Would I specify them with "context://" URLs?
> >
> > IOW will this work regardless of the sitemap that is processing
> the request?
> >
> > <map:match pattern="**.html">
> > <map:generate src="foo.xml"/>
> > <map:transform src="context://stylesheets/foo2xhtml.xsl"/>
> > <map:serialize/>
> > </map:match>
>
> This is in fact a problem. The Environment object which acts as a
> EntityResolver for the changable context root mentioned is not able to
> get at a component manager to lookup the URL factories (at least I
> haven't found a way). This leads to implement a context protocol in the
> EntityResolver part of the Environment as well.
>
> Any suggestion for an solution?
>
This is a problem I'm dreaming of over the last weeks. I first
thought of making even the Environment a component, so it could
declare itself as Composable and can get any component,
especially the URL factories.
But unfortunalety the creator of the environment, the servlet,
has no access to the component manager as well. So same problem.
I personally would like to have the component manager available
to the servlet as well, so it could use any configured avalon
component for initialisiation and configuration purposes.
But, again unfortunately, the only way I see currently to
get a component manager to the servlet is a simple hack of
Cocoon.java, declaring the component manager Cocoon uses
as public and the servlet can use it.
Any other solutions?
> Giacomo
>
Carsten
Open Source Group sunShine - b:Integrated
================================================================
Carsten Ziegeler, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
www.sundn.de mailto: cziegeler@sundn.de
================================================================
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [C2] Sitemap Mounting issue
Posted by giacomo <gi...@apache.org>.
On Thu, 19 Apr 2001, Berin Loritsch wrote:
> giacomo wrote:
> >
> > On Thu, 19 Apr 2001, Berin Loritsch wrote:
> >
>
> <Snip/>
>
> > > 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.
>
> (maybe I should have qualified it to _servlet_ developers)
>
> You presented some convincing arguments regarding the way it is set up now.
> There is still the redundancy issue with stylesheets. How do I use a
> specific stylesheet without having 10 copies of them based on where the
> map is mounted.
I see I've never thought about them.
> We have a series of stylesheets that all pages are sent through so that we
> have a uniform look and feel. I am trying to keep the modularity up and
> the rework down. Would I specify them with "context://" URLs?
>
> IOW will this work regardless of the sitemap that is processing the request?
>
> <map:match pattern="**.html">
> <map:generate src="foo.xml"/>
> <map:transform src="context://stylesheets/foo2xhtml.xsl"/>
> <map:serialize/>
> </map:match>
This is in fact a problem. The Environment object which acts as a
EntityResolver for the changable context root mentioned is not able to
get at a component manager to lookup the URL factories (at least I
haven't found a way). This leads to implement a context protocol in the
EntityResolver part of the Environment as well.
Any suggestion for an solution?
Giacomo
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [C2] Sitemap Mounting issue
Posted by Berin Loritsch <bl...@apache.org>.
giacomo wrote:
>
> On Thu, 19 Apr 2001, Berin Loritsch wrote:
>
<Snip/>
> > 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.
(maybe I should have qualified it to _servlet_ developers)
You presented some convincing arguments regarding the way it is set up now.
There is still the redundancy issue with stylesheets. How do I use a
specific stylesheet without having 10 copies of them based on where the
map is mounted.
We have a series of stylesheets that all pages are sent through so that we
have a uniform look and feel. I am trying to keep the modularity up and
the rework down. Would I specify them with "context://" URLs?
IOW will this work regardless of the sitemap that is processing the request?
<map:match pattern="**.html">
<map:generate src="foo.xml"/>
<map:transform src="context://stylesheets/foo2xhtml.xsl"/>
<map:serialize/>
</map:match>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [C2] Sitemap Mounting issue
Posted by giacomo <gi...@apache.org>.
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"
src="cvs:pserver:anonymous@xml.apache.org://home/cvs/cocoon/xdocs/{1}"/>
</map:match>
<map:match pattern="bugs/*">
<map:mount uri-prefix="bugs/{1}" check-reload="true"
src="jar://apps/bugs.cocoon#{1}"/>
</map:match>
As you can easily see there is not such "common" context among mounted
sitemaps.
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.
Giacomo
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org