Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Message-ID: <3FFAB432.5070607@gmx.net>
Date: Tue, 06 Jan 2004 14:12:18 +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: Re: [Suggestion] Making components easier to distribute
References: <3FFA9396.8070801@gmx.net> <3FFAAE8C.3040201@apache.org>
In-Reply-To: <3FFAAE8C.3040201@apache.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Giacomo Pati wrote:

>
>
> 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"
>            logger="your.logger"
>            role="your.interface.Name"/>
>
Oh, fine. I didn't knew about this.

>> 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 
> (http://wiki.cocoondev.org/Wiki.jsp?page=Blocks)?

No I'am sorry. But now I had read some parts of it. It looks really good 
and seems to solve my problem in future.

PS: Is there a timeline avaibale when 2.2 wille be approx released? In 2004?

Thank you.

Stephan