cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <dani...@nada.kth.se>
Subject Re: [RT] Block usage
Date Fri, 27 May 2005 08:17:30 GMT
Nathaniel Alfred wrote:

>>-----Original Message-----
>>From: Daniel Fagerstrom [mailto:danielf@nada.kth.se]
>>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


Mime
View raw message