You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Carsten Ziegeler <cz...@apache.org> on 2005/03/30 11:34:54 UTC
[RT] Bidirectional relationships for blocks?
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?
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: [RT] Bidirectional relationships for blocks?
Posted by Stefano Mazzocchi <st...@apache.org>.
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?
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.
Re: [RT] Bidirectional relationships for blocks?
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Carsten Ziegeler wrote:
> Ralph Goers wrote:
>
>>Carsten Ziegeler wrote:
>>
>>>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.
>>>
>>
>>I don't see this as a circular dependency. While portlets are certainly
>>dependant on the portal block, the converse is not true. The portal has
>>a dependency on the interface that portlets implement, not the actual
>>portlets themselves. Presumably, they are simply "looked up". Anything
>>else would be like saying Avalon is dependent on Cocoon, which certainly
>>is not true.
>
> Ah, ok, I see your point - yes, you're right. But somehow you have to
> tell the portal how to get the portlets. Perhaps this is a different
> issue. Hmm..
It should be composition: an application is composed of portal block and several
portlet blocks. Application then will know its portlets, and it can feed this
knowledge into the portal, one way or another...
Vadim
Re: [RT] Bidirectional relationships for blocks?
Posted by Carsten Ziegeler <cz...@apache.org>.
Ralph Goers wrote:
> Carsten Ziegeler wrote:
>
>
>>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.
>>
>>
>
> I don't see this as a circular dependency. While portlets are certainly
> dependant on the portal block, the converse is not true. The portal has
> a dependency on the interface that portlets implement, not the actual
> portlets themselves. Presumably, they are simply "looked up". Anything
> else would be like saying Avalon is dependent on Cocoon, which certainly
> is not true.
>
Ah, ok, I see your point - yes, you're right. But somehow you have to
tell the portal how to get the portlets. Perhaps this is a different
issue. Hmm..
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: [RT] Bidirectional relationships for blocks?
Posted by Ralph Goers <Ra...@dslextreme.com>.
Carsten Ziegeler wrote:
>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.
>
>
I don't see this as a circular dependency. While portlets are certainly
dependant on the portal block, the converse is not true. The portal has
a dependency on the interface that portlets implement, not the actual
portlets themselves. Presumably, they are simply "looked up". Anything
else would be like saying Avalon is dependent on Cocoon, which certainly
is not true.
Ralph
Re: [RT] Bidirectional relationships for blocks?
Posted by Reinhard Poetz <re...@apache.org>.
Daniel Fagerstrom wrote:
> Sure, seem like a good idea, but I found it hard to understand why you
> disregard my practical experience
Sorry if you've got the feeling that I desregard your practical experience. This
isn't my intention at all. I'm just curious to see what the difference between
multiple block inheritance and single block inheritance + composition, or in
other words, what the difference between yours and Stefano's solution looks like
in a *practical* example (I heard that *you* have practical experiences but I
want to learn a bit from them). I read several pros and cons for both solutions
but it's difficult for me to imagine how both solutions "feel" for me and which
one I like more.
Usually when I have such a problem I start to draw interface diagrams and write
some mocks implementating them. I will do the same here - of course this will
not be the super-example portal/portlet-integration ;-)
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: [RT] Bidirectional relationships for blocks?
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
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
Re: [RT] Bidirectional relationships for blocks?
Posted by Ralph Goers <Ra...@dslextreme.com>.
Carsten Ziegeler wrote:
>He he, I usually agree with your approach, but this time, it's too
>complicated for me. My real-world use-case is that I'm thinking about
>using cocoon blocks as a mechanism to write portlets for the cocoon
>portal engine. You end up with having the portal engine block and
>several portlet blocks. And here you exactly need the scenario I
>described. Sorry, but I will not provide a prototype for this :)
>
>So my question is: does this make sense?
>
>Carsten
>
>
>
Sure, it makes sense that "cocoon portlets" could be blocks unto
themselves. In fact, that would be a great way to separate the portal
functionality from the portlets. The portal just needs a way to discover
they are there.
Ralph
Re: [RT] Bidirectional relationships for blocks?
Posted by Carsten Ziegeler <cz...@apache.org>.
Reinhard Poetz wrote:
>
> 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.
>
He he, I usually agree with your approach, but this time, it's too
complicated for me. My real-world use-case is that I'm thinking about
using cocoon blocks as a mechanism to write portlets for the cocoon
portal engine. You end up with having the portal engine block and
several portlet blocks. And here you exactly need the scenario I
described. Sorry, but I will not provide a prototype for this :)
So my question is: does this make sense?
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: [RT] Bidirectional relationships for blocks?
Posted by Reinhard Poetz <re...@apache.org>.
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. 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
--------------------------------------------------------------------
Re: [RT] Bidirectional relationships for blocks?
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
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