cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Hartle <>
Subject Re: [RT] Avoiding Cocoon Thermal Death
Date Wed, 13 Mar 2002 17:01:37 GMT
Stefano Mazzocchi wrote:

>           +---------------------------------------------+
>          | I propose the adoption of the Avalon Block  |
>          | design pattern to modularize Cocoon's user  |
>          | level and avoid the increase of disorder.   |
>          +---------------------------------------------+
Cool !

>This, in short means:
> 1) Cocoon will be seen as an empty container. Provides basic framework
>functionalities and block containment, but no feature on its own. This
>explicitly resurrect the IoC pattern used in servlet engines, where the
>functionality is packaged in servlets or webapps and the servlet engine
>only provides services around that, with inverted control.
> 2) User functionality will be encapsulated in Cocoon Blocks. Using
>Cocoon will mean to deploy one or more Cocoon Blocks on top of Cocoon.
>These blocks will be *mounted* on a specific URI point and will be
>called by Cocoon when they need to act (follows the IoC pattern).
Sounds good.

- Does this mounting also apply to "non-URI-visual" blocks in your 
vision ? Some blocks expose themselves as web applications, some provide 
features for others, but are not useful seperately, like skins or 
"webapp language/i18n packages" or the like.

- Does mouting on a specific URI point speak of the public/web URI space 
? As we can have pipelines that are internal-only, a similar feature to 
a block might extend that thought.

> 3) These Cocoon Blocks contain file resources (raw or precompiled) and
>compiled bytecode (as individual classes or JAR libraries).
Each block brings it's own Jar's along ? Would something like a 
"library" Cocoon Block containing JARs, generators and the like make sense ?


>   d) a URI-based protocol will allow polymorphic access to cocoon blocks
>and inter-block sharing of resources. The proposed syntax is
>  block(role):/path/file
>  block(role):component
>for example
>  block(skin):/stylesheet/document2html.xslt
>  block(calendar):date-generator
>NOTE: the above is compatile with the URI syntax as described in RFC
Oh, good to know; thanks for the link.

>In case the block role is ambiguous, it will be used as a namespace
>prefix, as in
> <map:match ...>
>  <map:generate src="block(role):/path/file"
>  <map:transform src="block(role):/path/file"
> </map:match>
>if the block-based URI is used in non-namespaced syntax (for example, in
>the flowmap), an API-based solution will be provided.
Declaring a namespace prefix for resolving role ambiguities looks a bit 
like a hack; if there is only one ambigious block role per 
map:generate/map:transform, we might as well use an attribute called 
role which would allow this "role override" feature.

A thought, when there is a role ambiguity, it will happen across the 
whole sitemap/flowmap, right ? So anyone developing in this situation 
will start to add xmlns:role/role to resolve block role name clashes at 
map:generate/map:transform-level, which does not sound right to me as it 
is too late. If we somehow added a block role resolution like 
<xmlns:some="thing"> does it for <some:test/> (perhaps in a section to 
the sitemap/flowmap or a seperate file), developers can have role names 
in their Cocoon Blocks resolved as they need in a consistent manner, and 
I guess we could handle block(role)-type URLs more easily in the 
SourceResolver than with the xmlns:role/role-attribute approach.

Best regards,

Michael Hartle,
Hartle & Klug GbR

To unsubscribe, e-mail:
For additional commands, email:

View raw message