cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <nicola...@apache.org>
Subject UnBlocking Blocks
Date Mon, 27 Jan 2003 10:25:56 GMT


Stefano Mazzocchi wrote:
> Antonio Gallardo wrote:
> 
>> I think it is time to start thinking in a plug-in technology for Cocoon.
> 
> 
> Yes, it's time, but our avalon container is not good enough for that 

Let's put down what is lacking, and what the intermediate goals are.

Avalon will do this now:
  - release Fortress
  - release Merlin extends Fortress
  - work on Avalon 5

Merlin is the thing that can give us real blocks.

> But I'm wide open to suggestions on how to move this forward.

This is basically what I have proposed at the last live-meeting:
IMHO blocks need to be done in a slow and steady manner, because we are 
walking on new ground and I don' twant CocoonHEAD to break for big changes.
Avalon will soon release Fortress, that is a ECM successor.

Now, blocks are needed for two reasons:

  1  - separate components development and deployment from Cocoon
  2  - dynamic loading, polimorphic usage and wizbang super extra 
inheritance

I see the first part much easier to accomplish than the second, and we 
could get to that point much easier.

Step 1 is the last iteration of the .jar blocks.
Step 2 is the .cob system.

What do we need to get to step 1, that will alleviate problems a lot?

  - loading of Avalon components from the block jars
  - loading of Cocoon components from the block jars
  - way of defining blocks in the sitemap
  - automatic download of blocks

I imagine a

  components
    blocks

section, where I can specify the block to use, and the default download 
location, and the Cocoon components to load.

Something like:

  <map:blocks repository="blah">
   <map:block name="batik" version="..."/>
   <map:block name="fop"   version="..."/>
  </map:blocks>

and

  <map:serializer mime-type="image/png"
                  name="svg2png"
                  src="o.a.c.s.SVGSerializer"
                  block="batik"/>

This way we just tell the component to be loaded from a specific block.

The automatic download of blocks is not a problem. Krysalis Ruper 
already is able to download things and has a nice version specification 
system, so that part is solved.

What remains is the automatic load from the block jar, and how to tell 
the sitemap to do it.

Given that Fortress is ECM2, and given that we are going to release 
soon, if we need some feature we can ask if it can support it and move 
to Fortress.

This will give us breathing room for Merlin and proper block implementation.

-- 
Nicola Ken Barozzi                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message