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:
skin:org.apache.cocoon.transformer/xslt
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
legacy.
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.
WDYT?
/Daniel
