Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: pass (herse.apache.org: domain of ml@wrinkledog.com designates
 207.162.210.50 as permitted sender)
Mime-Version: 1.0 (Apple Message framework v624)
In-Reply-To: <45944E75.9000502@nada.kth.se>
References: <d62d97d95c982f2101603f2fc7322abf@comcast.net>
 <45944E75.9000502@nada.kth.se>
Content-Type: multipart/alternative; boundary=Apple-Mail-38-480570402
Message-Id: <4b6779bc01ec27c6562ef96b43e92a3f@wrinkledog.com>
From: Mark Lundquist <ml@wrinkledog.com>
Subject: Re: What is the deal with "blocks"
Date: Tue, 2 Jan 2007 11:32:11 -0800
To: dev@cocoon.apache.org


--Apple-Mail-38-480570402
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=WINDOWS-1252;
	format=flowed


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

> As you can see there was a quite gradual divergence from the original=20=

> concept to what we have today. IMO it would be preferable to just use=20=

> 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"=20
things!

> As we have used the term block for the container aspect for so long we=20=

> probably have keep that (although "plugin" probably would be easier to=20=

> understand for outsiders).

To me, the term "plugin" has a distinct connotation: that of something=20=

conforming to some "plugin API" published by the hosting framework,=20
like in Eclipse or Maven.  In Cocoon, with the 2.1-style "blocks" there=20=

is (as Reinhard said) no contract in view at all, and in the new Blocks=20=

when we speak of the block "contract" we mean the block-specific=20
contract that expresses the service(s) provided by the block, right? =20
IIUC, the "interface" that makes a Block function like a plugin is not=20=

an API at all, rather it's the structure+content "conventions" (e.g.=20
COB-INF, etc.) that you spoke of... is that correct?  In that case, I=20
don't see "plugin" as a natural term to apply to either the old-skool=20
"blocks" or the c2.2 "Blocks".  I think "plugin" has the potential to=20
engender more confusion than it alleviates... :-/

IMHO, going forward the things like CForms, Ajax, Batik etc. should no=20=

longer be called "blocks" at all... rather  they should be called=20
"optional modules", because that's all they are.  They are Maven=20
"modules", and they are "optional" because you have the choice whether=20=

or not to name them in your POM (in 2.1, blocks were "optional" because=20=

you had the choice whether or not to build them, but... that was then,=20=

this is now! :-).  Even though these were called "blocks" before, I=20
don't think that should stand in the way of this nomenclature shift. =20
If all of a sudden we start talking about the "CForms module" instead=20
of the "CForms block", that's not going to cause anybody's brain to=20
melt.  It's pretty obvious what is going on and people will pick up the=20=

change readily.  Right now we have core/ and blocks/; I would propose=20
renaming the "blocks" directory to "optional", changing the=20
nomenclature in the docs, and the text of the "Block Samples"  section=20=

of the samples page rewritten (that's horribly out of date and was in=20
need of a rewrite even in 2.1!)

Don't you love nomenclature changes? [1]

Cheers,
=97ml=97

[1] =97=A0http://en.wikipedia.org/wiki/Knights_who_say_Ni


--Apple-Mail-38-480570402
Content-Transfer-Encoding: quoted-printable
Content-Type: text/enriched;
	charset=WINDOWS-1252


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


<excerpt>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.

</excerpt>

+100.  Please, please, yes.


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


<excerpt>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).

</excerpt>

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 <italic>build</italic>
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]


Cheers,

=97ml=97


[1] =97=A0http://en.wikipedia.org/wiki/Knights_who_say_Ni


--Apple-Mail-38-480570402--