You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Nicola Ken Barozzi <ni...@apache.org> on 2003/01/27 11:25:56 UTC
UnBlocking Blocks
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
Re: UnBlocking Blocks
Posted by Nicola Ken Barozzi <ni...@apache.org>.
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.
Yup.
>> - 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.
Ok.
>> 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="..."/>
</map:blocks>
and have the rest work exactly as now.
--
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
Re: UnBlocking Blocks
Posted by Stefano Mazzocchi <st...@apache.org>.
Nicola Ken Barozzi wrote:
>
>
> 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.
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.
> 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?
--
Stefano Mazzocchi <st...@apache.org>
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: UnBlocking Blocks
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Nicola Ken Barozzi wrote:
> Given that Fortress is ECM2, and given that we are going to release
> soon, ^^^^
Avaloners
Being multiproject %-)
--
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