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?
feels FS to me. Bidi relationships are *very* painful (living in a world of owl:inverseFunctionalProperty), I would strongly suggest to stay away from it.
-- Stefano.
