Oh, fine. I didn't knew about this.
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"/>
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
