Mark Lundquist skrev:
Hi, I've been wanting to ask this question in one form or another for at
least the last year, but never gotten around to it until now... at
various points I've scanned the archives for the early discussions about
"real blocks", and skimmed discussions btwn. Daniel and others on the
dev list as they went by, which by that time were too advanced for me to
really follow...
There are two different meanings of "block", right? :-)
It is somewhat right, but not entirely.
The first sense of "block" denotes an optional part of Cocoon, e.g.
"forms", "batik", "html", etc.). In 2.1 we would configure
local.blocks.properties to include or exclude blocks from the build.
A block in Cocoon is analogous to a plugin in Eclipse or a bundle in
OSGi. It is a container, containing Java classes, resources and services
(components).
This has been the case for our implementations all the time and we have
no plans to change it. Considering packaging, deployment, dynamism and
features the Cocoon blocks are improving:
In Cocoon 2.1 a block is a directory with source code and some external
configuration files that need to be deployed with a fairly complex ant
script.
In Cocoon 2.2 a block is just a jar which follows some conventions. If
you drop a block into WEB-INF/lib in a "Cocoon webapp" and start it, the
block will be automatically deployed.
In the next generation of Cocoon, a Cocoon block will be an OSGi bundle,
this will provide classloader isolation and infrastructure for
dynamically installing, updating and removing blocks in a running system.
The second sense — I'll refer to it as "Block", with a captial "B" — is
apparently something different, with new protocols, etc., which is
implemented by the cocoon-blocks-fw module.
In the original proposals for the block architecture a block also
contained a special "block sitemap" that could be called from a "block
sitemap" in another block using a special "block protocol".
While working on implementing the original block proposal I after a
while come to the conclusion that the "block sitemap" aspect and the
"block as a container of classes, resources and services" aspect could
better be considered as separate concerns and be implemented independently.
Later I decided that there was nothing special with the "block sitemap"
processor it is just another service that a block can provide. I also
generalized it to make it possible for a block to provide a servlet
service rather than a more specialized sitemap processor service. There
where no reason for limiting a block to contain only one servlet service.
The cocoon-block-fw module contains the infrastructure for servlet
services. The most important class is the BlockServlet it is the class
that you configure in your Spring configuration for providing a servlet
service.
A BlockServlet can be configured to refer to other BlockServlets. Inside
the BlockServlet an internal BlockContext is setup, the BlockServlets
that it refer to can be called through the named dispatcher and the
context attributes and config params in the BlockContext can be
configured in the Spring configuration for the BlockServlet. Instead of
using the named dispatcher a special block protocol can be used.
The BlockServlet can be considered as a minimal webapp container and
inside it a servlet as e.g. the SitemapServlet can be executed. The
cocoon-blocks-fw module also contain mechanisms for polymorphic
BlockServlet inheritance and for rewriting block protocol URIs to
absolute URIs.
This terminology overloading is kind of confusing even to me, and I'm
not really a newbie anymore... is there a plan to resolve the
nomenclature issue?
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.
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).
It would probably be better to find some other terminology that not use
the word "block" as prefix for the polymorphic servlet service
infrastructure in the cocoon-blocks-fw.
Observe however that the terminology still is unambiguous while
unnecessary confusing:
block - a container containing classes, resources and services
block servlet, block context, block protocol - participants in the
servlet service infrastructure.
Or is the intent that all of today's "blocks" will
someday become "Blocks", or what?
No, blocks will continue to be containers, although more sophisticated such.
-o0o-
So what do you/others think? Is it still possible to improve the
terminology? Should we do it? And what terminology should we use instead
in such a case?
/Daniel
