cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: [RT] Implementing Cocoon Blocks
Date Sun, 14 Sep 2003 17:21:25 GMT

On Sunday, Sep 14, 2003, at 18:31 Europe/Rome, Vadim Gritsenko wrote:

>> if you wish to have proper names, that would be a comman line 
>> property away. This, for example, is useful for those projects that 
>> might wish to still distribute a complete war (forrest comes to mind) 
>> where the wiring.xml file is generated at build time.
> So the answer will be then: those directories are generated during 
> build time.

It is entirely possible to create a build process that creates the 
wiring.xml file without using the block deploying tool. I think cocoon 
apps like Forrest/Lenya might want to choose two types of distribution: 
a big war with all the blocks pre-expanded and the wiring.xml generated 
at build time and another one as blocks to be deployed on top of an 
existing cocoon.

The first distribution is for those who don't have a cocoon already 
installed, the second will be for those who do.

>  Is there a way to drop in block into expanded war and have block 
> deployer pick it up?

It could be possible, but only if there is no polymorphic behavior 
associated to the dependencies of that block. Otherwise, human 
intervention to choose which block implementation would implement the 
required block behavior cannot be avoided.

> Deployer will have to then pick up block from some directory, generate 
> 123456789 directory, and unpack block there, all in runtime, after the 
> build time.

This is entirely possible, but, as I said, only if there is no need for 
human choices which are:

  1) polymorphic implementation choice
  2) deploy-time configuration

The process can be automated, but not as much as for WARs because WARs 
are much less capable than blocks.

>>>> Unpacked blocks:
>>>> Good question -- maybe in WEB-INF/blocks ?
>>> I'd suggest to store blocks in WEB-INF/blocks/, and unpack/wire/etc 
>>> them into $temp/blocks, where $temp is temporary directory 
>>> configured in web.xml. WEB-INF/blocks/ can also have blocks.xml to 
>>> point out to blocks which are located outside of the blocks 
>>> directory, for development needs.
>> that might be a solution, but would force us to consider blocks 
>> "read-only" because, otherwise, if a block writes something on its 
>> internal file system, that content is not guaranteed to be >> persistent.
> We can either provide block deploy directory which will not be 
> dependent on container behavior (like we allow specifying work 
> directory in web.xml), or provide block temp directory.

well, which is what we do with WEB-INF/blocks/, don't we?


View raw message