cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: What is the deal with "blocks"
Date Tue, 02 Jan 2007 22:36:21 GMT
Mark Lundquist skrev:
> 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" things!

-100 ;)

Seriously, we have used the term block for the container aspect for like 
  5 years, and it is used in that sense everywhere in the documentation, 
code and in the mailing list. People would be seriously confused if we 
tried to change that now.

Finding some term that doesn't contain the word block for "polymorphic 
servlet services", would be much less of a problem as it is different 
from the original block concept and not that many people have used the 
blocks-fw yet.

So if someone have suggestions for a better terminology for the 
"polymorphic servlet services" I at least would be prepared to go for it.

>     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... :-/

Already 2.1 blocks provides services, classes and resources. Eclipse 
plugins also provide services, classes and resources. It is not that 

> 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!)

Maven modules OTH just provide classes and resources, no services.

> Don't you love nomenclature changes? [1]

Actually, no ;)


View raw message