Nathaniel Alfred wrote:
-----Original Message-----
From: Daniel Fagerstrom [mailto:[EMAIL PROTECTED]
Sent: Donnerstag, 26. Mai 2005 15:42
To: dev@cocoon.apache.org
Subject: Re: [RT] Block usage
a block deployer block
Basically the block deployer will be a stand-alone application (Ant
task, Maven plug-in, Eclipse plug-in, ...). Of course somebody could
write a web interface for it which could be a cocoon block.
As you can see in my original message I proposed: a block deployer
block, a block depoyer webapp block. Web interface and functinality
should cleary be kept separately.
Having read the OSGi whitepaper but not having followed in detail the
discussion about the vision of "real blocks", I am confused now.
Aren't OSGi bundles already what Cocoon blocks want to be? "Just"
package each block into a bundle with the right dependencies and
deploy it into the OSGi kernel.
What am I missing?
The OSGi bundles solves an important and technically complicated part of
the "real blocks". Everything we do today with the current "compile time
blocks" will be possible to do in a much more convenient way with OSGi
bundles, using their mechanisms for deployment, packaging, dependency
resolution, classloader isolation etc.
But the block vision doesn't stop there (see
http://wiki.apache.org/cocoon/BlockIntroduction for an introduction and
http://wiki.apache.org/cocoon/Blocks for more details). In a layer above
the bundle mechanism blocks can also acts as component containers and
one block can ask another one for components.
In the top layer, a block can offer sitemap services. Here the relation
between a block and the kernel is somewhat analogue to the relation
between a servlet and the servlet container. A block can contain a
sitemap it can be mounted at a certain URL during deployment, it can
contain parameters that are bound at deployment time. There is also a
block: protocol that is kind of extended cocoon: protocol for block
usage. A block can call piplines in another block through the block:
protocol. There will be a certain transformer that rewrites block: URLs
to their mount point.
Also blocks are somewhat like objects in OO, they can implement
interface blocks and they can extend another block. An extending block
can polymorphically override URLs in the extended block.
The sitemap aspect of blocks is not just a better way to do something we
really have it provides a new and more structured way to create reusable
webapps, see point 5 in my original message in this thread for an example.
More details can be found in the references above.
The sitemap aspect of blocks is on its way. I'm hopefully just a few
working days from a first version. Just need to find time for actually
doing it.
/Daniel
