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 Sat, 16 Mar 2002 02:10:47 GMT
Stefano Mazzocchi wrote:

>Michael Hartle wrote:
>>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.
>Yeah, that would work. Good idea.
>>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.
>Gosh, I think I lost you here. sorry :/
No problem, I will try to clarify my statement. Lets assume I am writing 
a cool new Cocoon Block and I am running into role name ambiguities, so 
currently I would be writing something like

    <map:generate src="block(specialrole):/path/file" 
    <map:transform src="block(specialrole):/path/file" 

using role overriding all the time to explicitly declare what is meant 
by talking about the block "somerole". This is cumbersome; it would be 
better to add something like

      <map:block-role name="yourspecialrole" 
      <map:block-role name="myspecialrole" 

    <map:generate src="block(yourspecialrole):/path/file"/>
    <map:transform src="block(myspecialrole):/path/file"/>

which has the following benefits:

* The block developer resolves all ambiguities himself in a consistent 
manner local to his block by assigning meaningful, unambigous block-role 
names; this approach somehow resembles the use of namespace prefixes in 
XML, as I can choose the prefix I want to use for a given namespace.

* A map:block-role section essentially contains all dependency 
information regarding the block that will be useful in the deployment 

* This should eleminate most of the need for the "role override" feature 
as you can map additional block-role names.

BTW, while we are still thinking about possible endings for blocks, what 
about .cba or .cbar (Cocoon Block Archive) ?

Best regards,

Michael Hartle,
Hartle & Klug GbR

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

View raw message