cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <>
Subject Re: UnBlocking Blocks
Date Tue, 28 Jan 2003 09:26:52 GMT

Stefano Mazzocchi wrote:
> Nicola Ken Barozzi wrote:

>> 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.
> True, I see wisdom in your thinking.
> Only a few details... see below.
>> 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
> this should be future compatible with the planned cob design, otherwise 
> we'll break things again.


>>  - 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.
> As far as classes go (avalon and cocoon components), don't forget that 
> we already have unique identifiers, so the sitemap should not include 
> that information but it should be somewhere else, and should be treated 
> by the classloader as a way to know where to get stuff.

You mean the block="batik" attribute in the serializer.
I didn't like it when I post it, and I like it even less now ;-)

>> 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.
> Uh, cool, didn't know that.
>> What remains is the automatic load from the block jar, and how to tell 
>> the sitemap to do it.
> As I said, I don't think the sitemap should be any different from that 
> is now. It should be the classloader's concern to know where to get 
> those classes.


>> 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.
> I'm +1 on implementing blocks incrementally, but only if this doesn't 
> require to break things later on (like atting the block="" attribute 
> first and then remove it later)
> what do you think?

Agreed. But we do need to have a <map:blocks>, no? We have to specify 
the version and the name of the blocks, so it should simply be:

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

and have the rest work exactly as now.

Nicola Ken Barozzi         
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)

To unsubscribe, e-mail:
For additional commands, email:

View raw message