cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Torsten Curdt <tcu...@dff.st>
Subject Re: [RT] user-components.xconf
Date Sun, 10 Mar 2002 15:57:58 GMT
guys, could you share your visions or RT on this... I don't want this 
thread to be just dropped without any result.

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?
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?
Please, I can't wait hear your RT on this!!
--
Torsten


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


Mime
View raw message