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]
