cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Giacomo Pati <>
Subject Re: [Suggestion] Making components easier to distribute
Date Tue, 06 Jan 2004 12:48:12 GMT

Stephan Coboos wrote:
> Hello,
> I like the concept of own avalon components in cocoon very very well. So 
> I only work with flowscripts and avalon components but very seldom with 
> actions or xsp. I think, the concept flowscript + avalon component is 
> the future way to integrate logic into a cocoon app. But in my opnion 
> there are a bunsh of disadvantages creating avalon-components in cocoon:
> 1.) Why it is necessary to extract the cocoon.roles from the cocoon.jar 
> to register the components? 

It is not necesssary. You can either make your own roles.file and 
indicate that in cocoon.xconf like:

<cocoon version="2.0" user-roles="/WEB-INF/user.roles">

or just use the full component descriptor as you'll find some in that 
form in the cocoon.xconf:

<component class="your.class.Name"

> For me at the first time I had done this, it 
> has looked like a change on the whole cocoon archticture and not a 
> simple integration of a logic component. I think its not clear why do 
> so. It looks like this is not the suggested way to intregate business 
> logic. But it is, isn't it?
> My suggestion:  The cocoon.roles should be situated in the classes 
> folder, not in the cocoon.jar or better in  WEB-INF beside the 
> cocoon.xconf aso.

No. the cocoon.roles file is a private one for cocoon only. If you are 
in need of your own write as mentioned above.

> 2.)  Its very hard to create independent components for customers. What 
> I mean is: Using a component in flowscript is relativley simple (the 
> customer is able to use this;-) but creating a component can be very 
> hard and complex. So it's possible that a new market place grows up in 
> which avalon-components for cocoon will be created and distributed 
> (Mailer-Component, DB-Component, aso.). But moving a component from one 
> cocoon-app to another cocoon-app can be very hard, too (4 steps and more 
> for moving are to much). So it should not be necessary to register all 
> roles in the same roles.cocoon and configure it in the same 
> cocoon.xconf. In my opinion the best way would be to distribute a new 
> component as jar which has its on "cocoon.roles" and "cocoon.xconf" in 
> it. Cocoon should "mount" these config files at startup. The 
> disatvantage of this order is, that the "real" config files are 
> separated from the one in the components jar. But cocoon should look at 
> startup into the real cocoon.roles and cocoon.xconf. Is the role already 
> registered and configured there, this configurations will be used. 
> Otherwise the configurations from the jar will be used.

Have you read about the Blocks comming with version 2.2 

Giacomo Pati
Otego AG, Switzerland -
Orixo, the XML business alliance -

View raw message