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:
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=111217990709705&w=2 ?
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.
/Daniel
|