cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Lundquist>
Subject Re: What is the deal with "blocks"
Date Tue, 02 Jan 2007 19:32:11 GMT

On Dec 28, 2006, at 3:08 PM, Daniel Fagerstrom wrote:

> As you can see there was a quite gradual divergence from the original 
> concept to what we have today. IMO it would be preferable to just use 
> the word "block" in one of the two uses of the the word.

+100.  Please, please, yes.

I really think that "block" should be reserved for the new "Block" 

> As we have used the term block for the container aspect for so long we 
> probably have keep that (although "plugin" probably would be easier to 
> understand for outsiders).

To me, the term "plugin" has a distinct connotation: that of something 
conforming to some "plugin API" published by the hosting framework, 
like in Eclipse or Maven.  In Cocoon, with the 2.1-style "blocks" there 
is (as Reinhard said) no contract in view at all, and in the new Blocks 
when we speak of the block "contract" we mean the block-specific 
contract that expresses the service(s) provided by the block, right?  
IIUC, the "interface" that makes a Block function like a plugin is not 
an API at all, rather it's the structure+content "conventions" (e.g. 
COB-INF, etc.) that you spoke of... is that correct?  In that case, I 
don't see "plugin" as a natural term to apply to either the old-skool 
"blocks" or the c2.2 "Blocks".  I think "plugin" has the potential to 
engender more confusion than it alleviates... :-/

IMHO, going forward the things like CForms, Ajax, Batik etc. should no 
longer be called "blocks" at all... rather  they should be called 
"optional modules", because that's all they are.  They are Maven 
"modules", and they are "optional" because you have the choice whether 
or not to name them in your POM (in 2.1, blocks were "optional" because 
you had the choice whether or not to build them, but... that was then, 
this is now! :-).  Even though these were called "blocks" before, I 
don't think that should stand in the way of this nomenclature shift.  
If all of a sudden we start talking about the "CForms module" instead 
of the "CForms block", that's not going to cause anybody's brain to 
melt.  It's pretty obvious what is going on and people will pick up the 
change readily.  Right now we have core/ and blocks/; I would propose 
renaming the "blocks" directory to "optional", changing the 
nomenclature in the docs, and the text of the "Block Samples"  section 
of the samples page rewritten (that's horribly out of date and was in 
need of a rewrite even in 2.1!)

Don't you love nomenclature changes? [1]


[1] —

View raw message