cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: [RT] Bidirectional relationships for blocks?
Date Wed, 30 Mar 2005 12:16:52 GMT
Reinhard Poetz wrote:

> Daniel Fagerstrom wrote:
>> 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
> I think we should stop discussing this topic in this theoretical way, 
> at least I can't follow it anymore.

Didn't you read my example in: ? 
It's based on a number of webapps that are used in production for some 
of our customers. I don't find that "theoretical". If you wonder about 
details or don't understand the concepts, please ask.

> 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.

Sure, seem like a good idea, but I found it hard to understand why you 
disregard my practical experience in actually using one of the involved 
concepts in several *real* applications.


View raw message