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.
<snip/>
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.
/Daniel
