Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Message-ID: <3FFA9396.8070801@gmx.net>
Date: Tue, 06 Jan 2004 11:53:10 +0100
From: Stephan Coboos <cromosom@gmx.net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
 rv:1.5) Gecko/20031013 Thunderbird/0.3
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: [Suggestion] Making components easier to distribute
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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

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.

What do you think about these suggestions?

Regards
Stephan