cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: Blocks, Flow and Dependencies [was RE: Splitting xconf files step 2: the sitemap]
Date Wed, 12 Jan 2005 22:53:11 GMT
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.

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.


Mime
View raw message