Carsten Ziegeler wrote:
I might be wrong but I think up to now we only talked about one block
depending on another block and this is then a one-way relationship.
But what if we need a bidirectional relationship? I have currently two
examples:
a) Skins
We briefly talked about one use-case for blocks: skins. You factor out
the layout of your application into a skin block and then can simply
switch to a different block implementing the skin contract. Now, what if
the skin block needs some information from the "application block" like
some user settings or whatever?
b) Plugins or portlets
I could imagine to bundle portles for the cocoon portal engine as simple
blocks conforming to a cocoon portlet contract. So the portal block uses
the portlet blocks, but in addition a portlet block needs access to some
portal services.
The same would apply if you would use the block concept to implement
some kind of plugins.
Does this make sense? Or is this FS?
The kind of polymorphism I have been talking about atacks exactly the
scenarios you describe. And from having used it in a number of
applications that I have been involved in developing during the last
year I can tell that it is a really convinient to reuse and extend e.g.
skins, in this way. There might be other design patterns for this, but I
have not seen any as smooth yet.
/Daniel
