From: "Sylvain Wallez" <[EMAIL PROTECTED]>
> Bertrand Delacretaz wrote:
>
> >On Tuesday 05 March 2002 09:21, Torsten Curdt wrote:
> >
> >>. . .
> >>We should be able to have a separate configuration besides the
> >>configuration for the core components. We should be able to define a
> >>user.xconf. (or better user-components.xconf?)
> >>. . .
> >>
> >
> >From a user's point of view, being able to drop the .xconf and required
> >jars in a directory under mount/ would IMHO be a great first step
> >towards "pluggable cocoon apps":
> >
> >mount/my-app
> > sitemap.xmap
> > cocoon-config/my-components.jar
> > cocoon-config/my-jdbc-driver.jar
> > cocoon-config/my-app.xconf
> > docs/index.xml
> > . . .
> >
> >Currently this mount thing works great (even without stopping cocoon)
> >if you need just a sitemap and content files, but as you mention more
> >than that needs editing the global cocoon.xconf and/or copying jars
> >under WEB-INF.
> >
> In the interpreted sitemap engine, the <map:components> section is
> handled as regular component manager configuration (i.e. a .xconf file),
> so you can add any component you wish in it.
>
> The only piece that's missing is a classloader per subsitemap to load
> additionnal jars. But we should be careful with that since this places
> code in areas that are potentially visible from the client browser (the
> servlet engine hides the contents of WEB-INF). A solution could be for
> the sitemap engine (or Cocoon itself ?) to forbid access to all URIs
> containing 'WEB-INF/'.
I'm definately +1 on having some kind of user.xconf.
I'd be +10 for a directory where you can plug in Cocoon blocks. Yes, block.
>From a previous interesting discussion on the list, I understood that Cocoon
needs 3 levels of pluggability: components, blocks and apps. This is
probably reflected from the fact that it uses Avalon, and Phoenix is
organized this way.
1 Components
-------------------
Components are all components under ./components. Some are of Cocoon proper,
some used only by blocks.
2 Blocks
----------
blocks are the Cocoon proper components (Generators, Transformers, etc).
They may need Components, and they must not need other blocks. They should
be IMHO easily deployable.
3 Apps
--------
These are complete sitemaps. Currently they are under a ./mount dir; a
descriptor and packaging format could be defined like in web.xml.
Now we have 1 configured in cocoon.xconf, 2 in cocoon.xconf and
sitemap.xmap, and 3 in sitemaps.
We could have that Cocoon proper Components are defined in cocoon.xconf.
Blocks are defined in their descriptor, along with the components they
use-have inside. This could make it possible to use components in different
configurations, one for each Block. At last, sitemaps should be able to have
their configuration that imports the required blocks.
So:
a) cocoon.xconf (general cocoon conf)
b) a.xblock
b.xblock
c.xblock (one for eack Block)
c) sitemap.xmap
sitemap.xconf
subsitemap1.xmap
subsitemap1.xconf
subsitemap2.xmap (sitemap proper)
subsitemap2.xconf (blocks used)
One thing is missing: something in between blocks and apps. For example,
skinning is more than a block, but not a complete app... IMHO it could be
seen as an app that can be referenced via URI contracts like Stefano hinted
(IIUC). For this, each sitemap.xconf should also state eventual dependencies
to other apps.
Ok, this became a poor man's RT ;-) , trying to summarize very interesting
discussions and integrating with user-components.xconf proposal.
Does it make sense?
--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
