On Wednesday, Oct 8, 2003, at 19:22 Europe/Rome, Ryan Hoegg wrote:Rather than have cocoon blocks extend avalon blocks, I think cocoon blocks could use avalon blocks. Instead of having a /COB-INF and a /BLOCK-inf, perhaps we include avalon blocks in /COB-INF/lib and delegate their deployment to the avalon container. This could even allow cocoon blocks to provide avalon blocks to the container, as well as require them.
Hi,
I've been following the block design discussion and wiki evolution with great interest for a couple months now (blame Geoff). Blocks look wonderful, and I can't wait to develop my cocoon based applications as blocks.
I have a concern about the bundling of exposed avalon services with blocks. Specifically, in the recent thread about "Finishing the First Phase of Block Design" and on http://wiki.cocoondev.org/Wiki.jsp?page=BlocksDefinition I see some duplicated effort. As Stephen McConnell noticed, some of this functionality is already built, tested, and maintained in several avalon containers. Why not package avalon blocks/services/components in the way the container expects, and include them somewhere like /COB-INF/lib or /COB-INF/public/lib? Or, even cleaner separation can be had in some cases by deploying them to the avalon container independently.
If things are done this way, the problem noted in the thread I mentioned above could be completely avoided. There would be no need to expose classes through the block interface because all java would be exposed as avalon services.
I think this would simplify the block design greatly, and allow us to focus on cocoon-specific aspects.
Let me see if I get this right: you are proposing that we make cocoon blocks
somewhat extend avalon blocks and we have /block-inf/ for information on the java components and /cob-inf/ for all the remainding cocoon-specific things, in order to be able to reuse existing avalon code?
But how can I describe dependencies if one part uses implicit ones and the rest uses explicit ones?
-- Stefano.
It may help to distinguish between different types of dependencies:
1. Block dependency. As described in http://wiki.cocoondev.org/Wiki.jsp?page=BlocksDefinition and specified in http://wiki.cocoondev.org/Wiki.jsp?page=BlocksWiring . What we (I think) have been talking about in several threads.
2a. Avalon dependency by block. This would be some avalon service/component that is required by the block, and would be explicitly declared. An example might be a Transformer or the Flow engine.
2b. Avalon dependency by avalon block/component/service. This would be some avalon service that is required by an avalon service or block that is included with the cocoon block. For example, I have a UserManager service that depends on a UserRepository service, which could be implemented by an OJBUserRepository. If the cocoon block included the UserManager block, it might ask the Parent Component Manager for a UserManager, and might be provided with the OJBUserRepository.
2b is the situation in which I think we could leverage the work being done by the various avalon containers. We would not have to explicitly define transitive avalon dependencies, as the avalon container can infer those from the avalon block that we give to it.
-- Ryan Hoegg ISIS Networks http://www.isisnetworks.net
