Daniel Fagerstrom wrote:
<snip/>
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.
I totally and wholeheartedly agree with what you say.
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.
Great!
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.
If the scenario where we have several implementations of a block
interface (e.g. skin) and several instances of a given block (e.g.
CSS-Skin) with different configurations can be handled with a flat
central registry, then I'm totally fine with it. Go for it!
Sylvain
--
Sylvain Wallez Anyware Technologies
http://bluxte.net http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director
