cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geoff Howard <coc...@leverageweb.com>
Subject Re: [RT] Sitemap inheritance
Date Sun, 26 Oct 2003 22:31:55 GMT
Gianugo Rabellino wrote:

> Stefano Mazzocchi wrote:
>
>>> Probably I should be more aware of what kind of inheritance exactly 
>>> block introduce in your design.
>>
>> I might be wrong, but I think that the current block inheritance 
>> mechanism does exactly what you were describing in your previous emails.
>>
>>> So far I haven't been able to find anything explicitly oriented to 
>>> pipeline reuse/inheritance: it's pretty clear that components 
>>> (classes) will be inherited, and the same goes for resources, but 
>>> what about pipelines?
>>
>>
>> I'm not sure we are using the same terminology here. but let me give 
>> you an example of how the blocks will work:
>
>
> [...]
>
> As long as there is room for overriding, i.e.:
>
>  block a
>
>   ...
>   <pipeline>
>    <match pattern="*.html">
>     ... do something ...
>    </match>
>   </pipeline>
>   ...
>
>  block b extends block a
>
>   ...
>   <pipeline>
>    <match pattern="*.html">
>     ... do something different ...
>    </match>
>   </pipeline>
>   ...
>
> I'm fine with it. *But*, again, this is a block-only behaviour (works 
> as long as you have two blocks).
>
>
>>> To me, having inheritance only in blocks look a bit like saying that 
>>> you can extend only from java.*, while user classes have to be 
>>> always final. It's rough and inaccurate, but can you see my point?
>>
>>
>>
>> hmmm, not really. blocks are application level components that 
>> isolate your logic. this is exactly what you are going to need. it 
>> would be like saying that object orientation is overkill for 
>> datatypes and nothing is wrong with C unions.
>>
>> I do agree that it looks like overkill to come up with a block for 
>> your own stuff that you need to inherit, but i think that this will 
>> force you to define contracts betweeen stuff and this will help you 
>> later on (just like OOP datatypes vs. unions)
>>
>> but, supposing for a second we allow sitemap inheritance without 
>> blocks, how would you make it work for both?
>
>
> I guess that once you have pipeline inheritance, it would be easy 
> enough to have it working both on blocks and on "ordinary" user 
> configurations. But my strongest point is that Cocoon has a steep 
> learning curve already, and while I do foresee some benefits in having 
> *everything* packaged as a block, I still think that there should be 
> room for traditional (=sitemap on filesystem) Cocoon development.
>
> This is also good for development: if the cycle becomes "edit 
> sitemap->package as block->install in cocoon->fail->retry" I guess it 
> would just be too heavy for users.
>
> Keep in mind that we should account for non-Java savy users too, 
> people who might be uncomfortable in using jar techniques, edit 
> metafiles, running ant and so on. Today all that is required to run 
> Cocoon is XML knowledge and a text editor: if everything becomes a 
> block, Cocoon will remain just a Java-developer-centric application.
>
> In short: blocks should ease a Cocoon developer's life, and block 
> assembling should belong to the "programmer" domain. Normal users 
> should see only benefits from it. Or am I wrong?


I believe that the benefits from real blocks will be so monumental to 
the way people work with Cocoon that every application should be 
packaged as a block/group of blocks.  Much of the pain of developing 
with Cocoon (more than the first little tinkering) goes away.  We need 
to make sure blocks are not scary to people,  but I don't think this is 
going to be difficult.  I'd propose waiting until we have a first 
working draft before further investigating alternatives which replace 
blocks.

Geoff



Mime
View raw message