Carsten Ziegeler wrote:
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.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?
/Daniel
I think we should stop discussing this topic in this theoretical way, at least I can't follow it anymore. I propose developing a *mock application* (contains only configuration files and pseudo code) that shows all the features of real blocks. Then we can decide what we need (not).
I will try to come up with something useful (I need it anyway for the block-deployer) within the next few days.
--
Reinhard P�tz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}web(log): http://www.poetz.cc --------------------------------------------------------------------
