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]