cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph Goers <>
Subject Re: [RT] The block protocol
Date Tue, 05 Apr 2005 02:42:50 GMT
Daniel Fagerstrom wrote:

> is resolved in the same way as an ordinary external block URI. To make 
> this possible the role of being a super block must be identifiable 
> among the connections in the wiring info. Maybe by reserving the name 
> "super" for this case.
> /Daniel

A few  thoughts here (that aren't necessarily directed at you):
1. I may have missed some points in this discussion. When the email gets 
to be  long or quotes previous nested emails in their entirety I tend to 
just move on and ignore the post.  So, as a rule I would recommend 
keeping posts as short and sweet as possible.  If you'll notice, there 
have only been a few participants in these discussions. Maybe its just 
me, but I wonder if others aren't jumping in with their thoughts for the 
same reason.
2. I've noticed a few discussions that are mainly between you and 
Reinhard with other folks posting occaisionally. Although you two may 
come to agreement on some ideas, given item 1 I wonder if it actually is 
the concensus of the community. Maybe I'm wrong though, and maybe most 
of the commtters just aren't interested.
3. I've had a real problem with the previous "blocks" discussion and how 
it used the Portal as an example.  I'm not sure that it is actually 
understood what needs to happen with the portal to make it into a "real 
block".  The issue with the portal is that the framework (what would be 
the portal block)  requires quite a few definitions, both in components 
and in the sitemap. These definitions must be provided by the portal 
implementation. If the portal implementation must provide the 
definitions then there really is no need for a block protocol as there 
is nothing in the portal block to invoke, other than the sitemap 
components provided by it. In message, 
Reinhard said "The block "portal" only contains pipelines calls which 
the block "profile" provides in its sitemap

Portal block
- requires "MyProfile" that implements "profile"


The problem with this example is that is not how the portal works, nor 
would I ever want the portal to require that a block with a specific 
name be present as this prohibits two portal implementations from being 
present in the same webapp. In fact, these definitions must be in the 
application, not the portal block.


View raw message