cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <>
Subject Re: [RT] Sitemap inheritance
Date Tue, 28 Oct 2003 14:31:48 GMT
Sylvain Wallez wrote:
> The concern 
> is actually about the ease of use of what we can call "local blocks".
> I had talks with Stefano about the need to have blocks non-archive 
> blocks on the local filesystem for roundtrip time during development 
> (you don't want to build a cob file to test each time you change a 
> line). We can extend this behaviour to local blocks that allow 
> "non-librarian-aware" people to use the blocks mechanisms without having 
> to run a librarian server, package their blocks and all the associated 
> stuff.
> Implementation-wise, this may mean that the block deployer can rely not 
> only on a remote librarian server, but also on a local "blockpath" that 
> is queried first before the remote server.

Since this discussion started about a use-case, here it is:

Forrest has some standard sitemaps that are mounted in the main sitemap.
I can imagine that in the future each of these would be a block.

Now we enable users to change the sitemap and use their versions 
instead, by overcopying the standard version with their own. It would be 
nice if they could delegate back to the standard version if they don't 
have a match hit, so that they can just decorate it with their changes 
(and not have to copy in all the "standard" parts).

This needs some sort of inheritance. But if these sitemaps are blocks, 
then this would seem to be ok...

I don't have the real big fat itch of making inheritance now as long as 
blocks have it. When they will come, I'll do an assessment, and we'll 
see if the issues are still there.

In any case I'll hang around to see how things are proceeding, and help 
from a users's POV.

Nicola Ken Barozzi         
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)

View raw message