cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Hartle <mhar...@hartle-klug.com>
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 ?

<snip/>

>   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
>
>and 
>
>  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
>http://www.ietf.org/rfc/rfc2396.txt.
>
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"
>xmlns:role="http://www.role.com"/>
>  <map:transform src="block(role):/path/file"
>xmlns:role="http://www.myrole.org"/>
> </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: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message