cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reinhard Poetz <>
Subject Re: Two steps back... What is a block?
Date Mon, 04 Apr 2005 06:24:08 GMT
Pier Fumagalli wrote:
> Or the separation between kernel and application concerns...
> Sorry if I sound extremely silly now, but after having spent a week in 
> Japan, all the "wasabi" must have gone to my brain or something....
> In the two/theee last "longish" discussions on blocks ("[RT] composition 
> vs. inheritance in blocks", "Schema of block.xml", and "[RT] 
> Bidirectional relationships for blocks?")
> Everything was fine, until someone (I think it was Reinhard) talking 
> about extensions pointed out the difference beetween extending a 
> "sitemap" and a "component".
> Am I right in assuming that blocks, in the scope of this discussions are 
> _NOT_ an evolution of Avalon's block (and therefore, not at the end of 
> the day tied to the intrinsic Java implementation of Cocoon, or in any 
> way related to the parallel development of the kernel container), but 
> are the real thing, "Cocoon blocks"????
> If that's the case, the "component" case in the extension outlined by 
> Rainhard should not exist, right?

I'm not sure what you are referring to with "component case". I guess you mean 

comp = manager.getComponent("blockB:componentXYZ");


<map:match pattern="portal">
   <map:act type="portal:auth-protect">
     <map:parameter name="handler" value="portal-handler"/>
     <map:parameter name="application" value="portal"/>

     <map:generate type="portal:portal"/>
     <map:transform src="blocks://skin/styles/portal-page.xsl">
       <map:parameter name="user" value="{ID}"/>
     <map:transform type="core:cinclude"/>
     <map:transform type="portal:portal-coplet"/>
     <map:transform type="portal:portal-new-eventlink"/>
     <map:transform type="core:encodeURL"/>
     <map:serialize type="portal:html-include"/>


In my understanding a block provides three different services which can be 
extended and referenced (means blockA can use the service of blockB):

  - pipelines
  - flowscripts
  - components

We had two (very long) discussions about the two first. The third case hasn't 
been discussed (in detail) yet - at least not that I know of. I remember 
somebody else using the above syntax of component lookups and I simply reused it.

I have to admit that I haven't thought much about the consequences of this and 
maybe you can share your point of view with us (e.g. What the heck  is an Avalon 
block? ... and what's the difference to Cocoon blocks? How can componentX of 
blockA be reused in blockB?) If this stuff has already been discussed, a pointer 
to the discussion is more than enough :-)

Reinhard Pötz           Independent Consultant, Trainer & (IT)-Coach 

{Software Engineering, Open Source, Web Applications, Apache Cocoon}


View raw message