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 [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------