Michael Hartle wrote:
>
> 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.
Yes, I see it now and I think you are totally right, your solution is
much better, even if it requires semantic additions in the sitemap
(although I think they are ok since we are adding a big functionality).
What do others think of this?
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<[EMAIL PROTECTED]> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
