cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: [RT] user-components.xconf
Date Tue, 12 Mar 2002 22:32:42 GMT
Torsten Curdt wrote:
> 
> guys, could you share your visions or RT on this... I don't want this
> thread to be just dropped without any result.

yes, yes, the RT is coming..... sorry, but I didn't have time these
days... busy doing paied stuff (yes, unfortunately, I do have to eat
sometimes :)

> More RT from me:
> 
> Another possible sollution for a per cocoon application configuration
> would be to tie an optional xconf to (the mount point of) a sitemap.
> Although I'm quite sure if chaining of both of this is a valid
> assumption I am sure that every application will come with it's own
> sitemap. So dropping in the application currently means dropping a
> sitemap mount. Stefano, would you like to see this change, too?

Yes, I want this 'protected automount' as well.

> If not I see two ways of doing this.
> 
> 1) specify a xconf where the sitemap is mounted
> 
>     <map:mount uri-prefix="myapp"
>                src="myapp/"
>                reload-method="synchron"
>                check-reload="yes"
> 
>                configuration="myapp/myapp.xconf"
>     />
> 
>     Problem: I remember there was a snippet on the list mounting sitemaps
>              with a pattern. So each sitemap could only have the same
>              xconf. So this feels a bit like a kludge, too
> 
> 2) let the sitemap point to the configuration and roles
> 
>     a)<map:sitemap xmlns:map="http://apache.org/cocoon/sitemap/1.0"
>                    configuration="myapp.xconf"
>                    roles="myapp.roles"
>                    >
>         <map:components>
>           ...
>     b)<map:sitemap xmlns:map="http://apache.org/cocoon/sitemap/1.0">
>         <map:components
>               configuration="myapp.xconf"
>               roles="myapp.roles"
>               >
>           ...
> 
>     But thinking this way we shouldn't define the cocoon.xconf as serlvet
>     parameter but the root sitemap.
> 
>     So we would remove/deprecate
> 
>      <init-param>
>        <param-name>configurations</param-name>
>        <param-value>/WEB-INF/cocoon.xconf</param-value>
>      </init-param>
> 
>     And have
> 
>      <init-param>
>        <param-name>root-sitemap</param-name>
>        <param-value>sitemap.xconf</param-value>
>      </init-param>
> 
>      and
> 
>      <map:sitemap xmlns:map="http://apache.org/cocoon/sitemap/1.0">
>         <map:components
>               configuration="cocoon.xconf"
>               roles="user.roles"
>               >
> 
> On the other hand using the sitemap this way makes it more of a
> application descriptor than just a plain sitemap. For SoC we maybe
> should mount *applications* (or what you guys called it:blocks) not
> sitemaps.
> 
> So we would need something like a "Cocoon Application Descriptor"
> 
>    mounting the first one via WEB-INF/web.xml
> 
>      <init-param>
>        <param-name>root-app</param-name>
>        <param-value>cocoon.cad</param-value>
>      </init-param>
> 
>    with the cocoon demo application
> 
>     <cocoon-app>
>       <sitemap>sitemap.xmap</sitemap>
>       <roles>resource:/...</roles>
>       <configuration>cocoon.xconf</configuration>
>     </cocoon-app>
> 
>     and then mount inside the sitemap (the right place?) another
>     application:
> 
>     <map:mount uri-prefix="myapp" src="myapp/myapp.cad" />
> 
>     <cocoon-app>
>       <sitemap reload-method="synchron"
>                check-reload="yes">myapp.xmap</sitemap>
>       <roles>myapp.roles</roles>
>       <configuration>myapp.xconf</configuration>
>     </cocoon-app>
> 
> Stefano, is this more the direction you thought of?

Yes, definately.

> Please, I can't wait hear your RT on this!!

Coming off tomorrow, hopefully :)

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<stefano@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message