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. <[EMAIL PROTECTED]> Friedrich Nietzsche -------------------------------------------------------------------- --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
