cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: Roadmap for Cocoon Blocks
Date Tue, 11 Oct 2005 12:39:23 GMT
Reinhard Poetz wrote:
> 
> In Amsterdam at the GT Daniel gave a presentation 
> (http://cocoongt.hippo12.castaserver.com/cocoongt/daniel-fagerstrom-blocks-2.pdf) 
> about Cocoon blocks and one of his slides contained a roadmap for Cocoon 
> blocks. This roadmap was discussed in the breaks and AFAICT is was 
> widely accepted. Of course this doesn't mean that this is community 
> consensus as not all have had the chance to comment on this yet.
> 
> So here is the roadmap and let's discuss it "officially" on the mailing 
> list:
> 
> - Cocoon 2.2 will not use OSGi but will support blocks as far as possible:
>    - blocks protocol (= sitemap blocks)
>    - a block gets its own component manager that contains all local 
> components
>      and gets the block component managers of all wired blocks as parent.
>    - we use M2 as build and deployment tool (needs some special M2 plug-ins
>      for the deployment part)
>    - blocks are distributed as binaries
>    - blocks are *not* spread over different directories during deployment
>    - a block can contain classes in [block]/BLOCK-INF/classes that are 
> added
>      to the context classloader
> 
>    --> this means that everything, that real blocks promise, works 
> except the
>        shielding of Java classes.
> 
> - Cocoon 3.0 will use OSGi --> shielding classloader and hot plugablillity
> 
> 
> Although Daniel has emphasized this many times I want to repeat it: We 
> don't need to branch trunk for this roadmap. OSGi development can be 
> done in parallel and we can avoid the unsatisfying situation of 
> maintaining two branches.
> 
> 
> Of course future development can show that this or that is not possible 
> or should be done differently (who knows now, if OSGi will really make 
> it) but IMO it's nice to have a goal and something that we can 
> communicate to other projects that depend on Cocoon so that they have 
> enough time to adapt their design decisions.

I'm +1

One thing, though, remember to also have a LinkRewritingTransformer that 
is block aware so that we can do

  <style src="block:skin:/styles/main.css"/>

and this gets translated in the right URL (hopefully relative, so that 
we don't have issues with webapp proxying, or, if absolute, we need a 
way to configure where is the cocoon mountpoint as seen from the proxy side)

I'm currently doing

http://simile.mit.edu/repository/linotype/trunk/stylesheets/absolutize.xslt

with my latest linotype and I can't wait to get rid of all these hacks :-)

-- 
Stefano.


Mime
View raw message