cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: [RT] Avoiding Cocoon Thermal Death
Date Sat, 16 Mar 2002 11:01:05 GMT
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
> >>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=""/>
>     <map:transform src="block(specialrole):/path/file"
> role=""/>
> 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=""/>
>       <map:block-role name="myspecialrole"
> namespace=""/>
>     </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.
<>                             Friedrich Nietzsche

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

View raw message