cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: Schema of block.xml
Date Fri, 25 Mar 2005 19:02:58 GMT
Reinhard Poetz wrote:
> I think it's time to work on the contracts of blocks a bit more as I 
> want to start to move the blocks into /cocoon/blocks/[name]/trunk. As we 
> agreed that state information should be part of meta files, we also have 
> to agree how this meta file should look like in detail.


> It's widely the same as the XML Stefano proposed (long) time ago. I 
> added a "state" element that desribes the community (committed, 
> supported, deprecated), interfaces (stable, unstable) and implementation 
> (stable, unstable) state and has a link to resource that desribes this 
> in more detail.
> Comments?

Looks good. What I don't agree with is the single inheritance (extends 
and implements). I think that a typical use case will be that you build 
your webapp as a block. Then it will be quite natural to put it together 
   by extending a number of blocks that take care of things like 
skining, user handling, content management etc. You mount the URI spaces 
for these blocks relative to your own block and overrides 
(polymorphically) components and sitemap resources in the extended 
blocks with behaviour in your own.

We need IMO think a little bit more about what extends and implements 
means in the context of blocks. For example what if block A extends 
block B, will the concrete B block be determined first at deploy time? 
IMO it makes sense and creates more flexiblity than the extension 
mechanism in Java or C++. But it is quite different so we should try to 
understand the consequences.


View raw message