cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject [M10N] GroupId for blocks and layering of Cocoon
Date Wed, 11 Jan 2006 13:19:23 GMT
Was: Re: svn commit: r367714 - in /cocoon/trunk/cocoon-template: ./   
pom.xml src/ src/main/ src/test/

Carsten Ziegeler wrote:

>Daniel Fagerstrom schrieb:
>>Jorg Heymans skrev:
>>>Giacomo Pati wrote:
>>>Each block should have the same groupId yes. Should we make it
>>>o.a.c.blocks ? (in analogy with [1])
>>Everything will be a block, the core included, in analogy with [2]. So 
>>it would be redundant to introduce an extra level in the groupId.
>Hmm, don't we need some "bootstrapping", for example the cocoon servlet
>or the cli main class etc? I think these are not really blocks. Even if
>they are from an implementation pov, they are not from a functionality
>pov. So personally, I would distinguish between blocks and
>"bootstrapping" which could be core.
One of the goals from the NG discussions during the end of the last year 
was to make Cocoon less monolithic, and make it easier to reuse parts of it.

At the top layer in an layered Cocoon architecture I envision that we 
have "controllers" (that implement Servlet). The controller chain for 
large Cocoon systems would be:

  BlocksManager -> BlockManager -> [SitemapServlet | FlowscriptServlet | 
JavaFlowServlet | ... ]

In a small application with less need for modularization the controller 
chain might be just:


If we want the different controllers to be reusable it makes less sense 
to consider one of them a bootstrap layer.

The blocks framework is under refactoring to implement this vision.

                                   --- o0o ---

Until things has settled a little bit more I suggest that we keep the 
current flat layout with o.a.c as GroupId.

I also think that GroupId should reflect community structure rather than 
function. If we start to grow as a community and get clear sub 
communities that work on disjunct set of artifacts, it would make sense 
to have a more fine grained GroupId structure.


View raw message