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" 
role="http://this.is.yourrole.org"/>
    <map:transform src="block(specialrole):/path/file" 
role="http://that.is.myrole.org"/>

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-roles>
      <map:block-role name="yourspecialrole" 
namespace="http://this.is.yourrole.org"/>
      <map:block-role name="myspecialrole" 
namespace="http://that.is.myrole.org"/>
    </map:block-roles>

    <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 
process.

* 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: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Reply via email to