cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reinhard Poetz <>
Subject Re: [RT] The block protocol
Date Tue, 05 Apr 2005 07:26:17 GMT
Ralph Goers wrote:
> 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 
> 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}


View raw message