cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: [blocks] Changing component strategy
Date Wed, 25 Jan 2006 21:07:08 GMT
Sylvain Wallez skrev:
> Carsten Ziegeler wrote:
>> Daniel Fagerstrom wrote
>>> WDYT?
>> I'm not sure if a global registry really works. What happens if I want
>> to use a block twice but with different configurations? Can this be 
>> handled?
> Yep. How do we (can we) implement the classical scenario that's been 
> considered for blocks, i.e. the skinning with a "multi-skin" that 
> delegates to other skin blocks.

I'm not suggesting to change any of the semantics concerning 
configuration and wiring of sitemaps (or rather servlets in the current 
architecture), they will continue to work as before and as specified in 
various design documents.

The question is about the scope of registered components from a block.

If we should follow the pattern from the block protocol also for 
components, they would get name like:


but introducing block name spaces on component ids would require 
changing most of our current code. And I'm not certain about that such a 
component lookup scheme would be worthwhile even if we didn't have our 

What I did instead in the current implementation is that the component 
ids are exactly as before, but that each block has an own container, and 
this container has a parent container that search for a requested 
component in the containers of the requested blocks.

The search order is that first the own container is asked, then the 
connected blocks in the order the connections are listed and if there is 
a block that the current block extends, it is searched last. All the 
asked blocks ask their connected blocks in turn before returning an 
answer. So it will be a depth first search in the connection graph. 
There is no complete method for stopping circular searches implemented yet.

My current opinion about the just described scheme is that it is far to 
complicated and has a lot of disadvantages as I described in my original 
mail in this thread. Frankly, the scheme sucks, and I want to get rid of 
it ASAP, before it hurt some user. As I conceived it and implemented it 
and no one have cared to comment it until now, it shouldn't hurt anyones 
feelings ;)

               --- o0o ---

So what I want instead is the kind of mechanism that you implemented for 
the component management in the ECM OSGi services bridge.

My current view is that the declarative services manager in  OSGi R4, 
already have good solutions for component handling in a blocks context.

So I think it would be a waste of time to try to invent something 
conceptually different for Cocoon blocks. We should IMO keep our 
architecture as similar to the OSGi ones as possible.

That will also make it simpler to migrate to OSGi. And we will have a 
much easier time to reuse work and patterns from Eclipse, Felix and 
other communities that build on OSGi.

> In that scenario, application blocks depend on a block implementing the 
> "skin" contract, and the implementation chooses the actual skin block to 
> be used depending on some condition (user, time, host, whatever). That 
> means we'll have 3 implementations of the "skin" block interface in the 
> system, and possibly have several different instances of the e.g. 
> "myCorporateSkin" block with different configurations (color, 
> stylesheets, etc).

A skin block is basically a factory, and a wiring is an instruction to 
ask the factory for a component, give it its deploy time configuration 
and a unique id and to register the differently configured instances 
under the different ids in the global service registry. So the above 
scenario should not be a problem.

Now, in any case, we can't keep the scheme for component lookup that I 
have implemented. So we need something different. And if you don't like 
the OSGi inspired that I would like to go for, we need other suggestions.



View raw message