cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Glen Ezkovich <>
Subject Re: [RT] Cocoonlet
Date Wed, 27 Apr 2005 21:58:23 GMT

On Apr 27, 2005, at 3:39 PM, Vadim Gritsenko wrote:

> Daniel Fagerstrom wrote:
>> Our current (controversial ;) ) plan is to consider the sitemap and 
>> the component aspect of the original block proposal as separate 
>> concerns and (at least initially) solve them separately.
> I propose less controversial plan.
> As the first step, implement what you call "sitemap blocks", but call 
> them simply "blocks". Own classloader, full classloading isolation, 
> block protocol, exposing direct sitemap components: generators, 
> transformers, serializers.
> As the second step, implement "components block" *on top of* "sitemap 
> blocks". This introduces second classloader (one is public, to share 
> component interfaces, and one is private, to contain components 
> implementation and libraries), and logic for managing classloader 
> trees. Still call it simply "block".

Works for me. I think making distinctions among different types of 
blocks can only lead to confusion. After all, blocks are about 
component-izing Coccon. Much of the recent discussion has centered on 
the issues of extensibility and visibility. These issues, while 
important, are what makes the implementation of blocks complex. The 
incremental approach would be to develop block deployment and access 
mechanisms using the current sitemap mechanisms for controlling 
visibility, class loading, etc. Once that is accomplished the 
additional features can be incorporated one at a time. Evolving block 
features will likely lead to a better, more maintainable and extensible 
over all design. (Besides it will likely get real blocks here faster.)

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