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.
WDYT?
/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 http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=111245388030013&w=2, Reinhard said "The block "portal" only contains pipelines calls which the block "profile" provides in its sitemap
Portal block ------------ - requires "MyProfile" that implements "profile"
<profiles> <copletbasedata-load uri="blocks:profile:/load-global-profile?profile=copletbasedata"/> <copletdata-global-load uri="blocks:profile:/load-global-profile?profile=copletdata"/> .. </profiles>
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.
Ralph
