cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@apache.org>
Subject Re: [RT] Separation of Blocks and Avalon
Date Thu, 09 Oct 2003 22:18:01 GMT


Stefano Mazzocchi wrote:

>
> On Thursday, Oct 9, 2003, at 17:15 Europe/Rome, Ryan Hoegg wrote:
>
>> Rather than have cocoon blocks extend avalon blocks, I think cocoon 
>> blocks could use avalon blocks.
>
>
> Ok, I see your point.
>
>> 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.
>
>
> I would not know how to do this! I'm not scared by merlin, I'm scared 
> about the million little details that cocoon assumes on top of ECM and 
> that are now considered deprecated by the "modern" containers. 


The million little details that cocoon assumes on top of ECM is also the 
thing that scares me the most.

>
> if Fortress was there, admittedly, things would be easier... but then 
> again, lots of talks, but nobody is able, wants or has 
> time/energy/braveness to do the migration.


Is there someone who provide the breakdown of what Cocoon is doing over 
and above ECM?  However things roll out - one of the biggest obsticles I 
see is that we need to move away from ECM/Fortress extension and to a 
solution where Cocoon does not need to access container APIs.  With that 
information the Avalon crowd can address how to addres these 
requirements in a way that makes the concern indpendent of the container 
implementaiton.

>
>> 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.
>
>
> I fear the complexity of such a move. 


Break the complexity down into managable chunks.

1. migrate from Component to Object
2. migrate from roles files to meta

Just achiving the above opens up a much broader spectrum of 
possibilities and the question become much more concrete and substantive 
(from both sides of the equation). We have been discussing this over on 
Avalon land - subjects such as transition vehicles, migration tools, 
etc. these are way up on the agenda. 

Steve.

-- 

Stephen J. McConnell
mailto:mcconnell@apache.org




Mime
View raw message