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.
I have the same feeling - but discussing based on examples is difficult, especially if the examples are very long ...
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.
No, I don't think that everybody who hasn't contributed to the discussion is in agreement with Daniel, Stefano and me. It will be much easier when the first prototype is available.
Maybe I'm wrong though, and maybe most of the commtters just aren't interested.
I don't understand this. If somebody isn't interested, he shouldn't have a problem with the discussion. It's a bigger problem that if people *were* interested and don't like the long mails that they would have to say important things but they don't want to invest that much time in following the discussions.
As said in my reply to Betrand's mail, I will try to revise the original design proposal by Stefano (as far as I can see there are only some minor things that have changed or were extended + I will also add relevant links to mails)
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.
That's not true. You can deploy as many portal applications as real blocks as you want. And, if you don't like dependencies (references, extensions) just don't use them. The example above was for the sake of showing that things *can* be separated if people like it. E.g. you could deploy 5 portal applications all using the same skin block.
In fact, these definitions must be in the
application, not the portal block.
as said above, it's your choice. If you want to do things in the future as you have always done, put your application into a single block and only minor things will change for you (you have to provide a block.xml file, that's it).
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}web(log): http://www.poetz.cc --------------------------------------------------------------------
