After rereading much of this discussion and the various wiki pages concerning blocks I withdraw almost everything I said. Its now obvious to me that the way to achieve everything we are talking about is to allow for multiple inheritance. I am not recommending this since I have not thought deeply about its implications yet. Generally, I don't like multiple inheritance.
The reason I even bring this up is that it seems clear that there are two different ways we may want to use a block. One way is to just simply use a block through its sitemap and/or components it exposes. That is use one of its pipelines, VPCs or components directly from another block. The other way is to compose an application by combining several blocks. By using the extension mechanism you just need to override default configuration and other resource files to customize your application. For example we may put an e-commerce app together by combining authentication, shopping cart, store, shipping and webmail blocks. Because each of these blocks may have different looks and feels I may want to make sure that our app has a consistent L&F by overriding a few resources in each of those blocks. Likewise I may need to alter the checkout flow and can do so by overriding a single resource. This by far will be the easiest way to compose the app out of the various blocks and does not require hacks to the sitemap or any complex URI machinations by the developer.
How this for adding fuel to the fire. Ok... now you can tie me to a log and just toss me on top.
Glen,
I've thought deep and hard about the 'composition' patterns that real block should need and I realized that it's inherently bad practice to allow something without knowning how harmful it might be.
So, I would suggest we use the good old approach: keep it simple and add functionality only if somebody has enough itches to scratch.
In fact, real block alltogether might be overdesign, who knows.
If we got to implement what we already achieved consensus upon would be a great start. Not the end of reasearch in higher-order webapp composition patterns :-)
-- Stefano.
