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
different.
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 ;)
/Daniel
