Return-Path: 
 <cocoon-dev-return-23832-apmail-xml-cocoon-dev-archive=xml.apache.org@xml.apache.org>
Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org
Received: (qmail 29779 invoked by uid 500); 6 Mar 2002 11:31:56 -0000
Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:cocoon-dev-help@xml.apache.org>
list-unsubscribe: <mailto:cocoon-dev-unsubscribe@xml.apache.org>
list-post: <mailto:cocoon-dev@xml.apache.org>
Reply-To: cocoon-dev@xml.apache.org
Delivered-To: mailing list cocoon-dev@xml.apache.org
Received: (qmail 29768 invoked from network); 6 Mar 2002 11:31:55 -0000
Date: Wed, 6 Mar 2002 09:44:42 +0100 (CET)
From: giacomo <giacomo@apache.org>
X-X-Sender: <giacomo@lapgp.otego.com>
To: <cocoon-dev@xml.apache.org>, Nicola Ken Barozzi <nicolaken@apache.org>
Subject: Re: [RT] user-components.xconf
In-Reply-To: <003d01c1c42f$8be2fb20$670004c0@PC103>
Message-ID: <Pine.LNX.4.33.0203060939280.1509-100000@lapgp.otego.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N

On Tue, 5 Mar 2002, Nicola Ken Barozzi wrote:

> From: "Sylvain Wallez" <sylvain.wallez@anyware-tech.com>

<snipped/>

> > 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.

user.xconf as well as user.roles must be organized so that every Cocoon
Block has at least a set of it (we can discuss if it should be bound to
a sitemap, and thus be hierarchically organized instead of flat, but ...
FS?)

> 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.

As you mentioned Avalon Phoenix there Blocks CAN use other Blocks as a
Block is defined as a Service.

Giacomo


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