On Jan 12, 2005, at 4:53 PM, Stefano Mazzocchi wrote:
Glen Ezkovich wrote: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.
I doubt that, but I think you may want to limit its scope initially.
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 :-)
I agree completely. I just threw this out as a possible simplification from a user perspective. I am a firm believer in developing incrementally. Obviously, simple extension comes first. The problems that led to this thread should not be solved before we have basic blocks working.
By the way, I'm curious what you think about making a block's resources available. There are two conflicting wiki pages.
there is this
A block exposes a sitemap and Avalon Components (both optionally)
from http://wiki.apache.org/cocoon/GT2003RealBlocks
and this
A block exposes two types of services:
â components
â resources
â pipelines ??
from http://wiki.apache.org/cocoon/BlocksDefinition
the second of which gives the following as an example of accessing a resource.
 block:skin:/stylesheets/document2html.xslt
Glen Ezkovich HardBop Consulting glen at hard-bop.com http://www.hard-bop.com
A Proverb for Paranoids:
"If they can get you asking the wrong questions, they don't have to worry about answers."
- Thomas Pynchon Gravity's Rainbow
