Return-Path: 
 <cocoon-dev-return-13076-apmail-xml-cocoon-dev-archive=xml.apache.org@xml.apache.org>
Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org
Received: (qmail 4187 invoked by uid 500); 7 May 2001 12:56:18 -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 4169 invoked from network); 7 May 2001 12:56:13 -0000
Message-ID: <3AF69B8F.EEBB9B7E@anyware-tech.com>
Date: Mon, 07 May 2001 14:56:47 +0200
From: Sylvain Wallez <sylvain.wallez@anyware-tech.com>
Organization: Anyware Technologies
X-Mailer: Mozilla 4.7 [fr] (WinNT; I)
X-Accept-Language: fr,en
MIME-Version: 1.0
To: cocoon-dev@xml.apache.org
Subject: Re: can we move roles.xconf
References: <Pine.LNX.4.31.0105042240340.17389-100000@lap1.otego.com>
 <3AF69642.291ED696@apache.org>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N



Berin Loritsch a �crit :
> 
> giacomo wrote:
> >
> > I'd like to suggest to move the roles.xconf file out of the src tree
> > somewhere near to the cocoon.xconf file (BTW I'd like to move
> > cocoon.xconf and roles.xconf file into the WEB-INF directory).
> 
Isn't it "cocoon.roles" ?

> You can move cocoon.xconf anywhere you want.  The major issue is that
> the roles.xconf file should not be accessible outside the jar.  It does
> not contain anything that the average user should alter.  It's existance
> outside the Cocoon jar will generate alot of questions along the lines
> of "what is this roles.xconf file", "what can I change in there", and
> "I changed something and Cocoon doesn't work anymore".  It was separated
> out, because the roles.xconf file is PURELY a developer's concern--so
> it shouldn't be easily accessible.
> 
> > On the user list someone asked how to deploy own components without
> > access to the roles.xconf file because it is packed up into the
> > cocoon.jar.
> 
> Easy:
> 
> <component role="com.mycom.myproj.myrole" class="com.mycom.myproj.myclass"/>
> 
> Or if they have something that they need to do selection with:
> 
> <component role="com.mycom.myproj.myroleSelector"
>  class="org.apache.avalon.excalibur.DefaultComponentSelector">
> 
>   <component-instance name="foo" class="com.mycom.myproj.myclass"/>
>   <component-instance name="bar" class="com.mycom.myproj.myotherclass"/>
> </component>
> 
> > The location of the roles.xconf file should be declared similar to the
> > sitemap.xmap declaration in the cocoon.xconf file.
> 
> Not necessarily.
> 
> > Any volunteer for a simple patch :)
> 
> That patch will affect Avalon Excalibur--which is entering code freeze today.
> 
I totally agree that cocoon.roles is a developper concern, but when
Cocoon is the base of a bigger system which defines new components, it
would be nice to be able to define new roles for them instead of using
<component> elements.

What do you think of adding an optional attribute to the top-level
"cocoon" element that names an alternate roles definition file that is
loaded from the classpath, i.e. <cocoon role-defs="mysystem.roles"> ?
This affects only Cocoon.java, and not Excalibur.

-- 
Sylvain Wallez
Anyware Technologies - http://www.anyware-tech.com

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