cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Glen Ezkovich <>
Subject Re: Blocks, Flow and Dependencies [was RE: Splitting xconf files step 2: the sitemap]
Date Wed, 12 Jan 2005 23:50:41 GMT

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)

and this
> 	A block exposes two types of services:
> 	▪ 	 components
> 	▪ 	 resources
> 	▪ 	 pipelines ??

the second of which gives the following as an example of accessing a 
>   	block:skin:/stylesheets/document2html.xslt

Glen Ezkovich
HardBop Consulting
glen at

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

View raw message