Stefano Mazzocchi wrote:
Daniel Fagerstrom wrote:
<snip/>
in the connection section, where "http://mycompany.com/skins/corporate/34.3.345"; uniquely identifies the specific skin implementation that has been choosen at deploy time.
<comment>
Is the URI unique enough? What if I want several variants of the skin that has different deployment parameters and implementations of theire connections.
IIRC, URI is generated, at that time uniqueness is guaranteed by BlocksManager (who created the URI).
From http://wiki.apache.org/cocoon/BlockIdentification, I get the impression that URI is "universal" rather than locally generated at deploy time. I agree that a unique identifier created at deploy time by the BlocksManager is needed.
I disagree. You have a world-wide unique identifier (the URI) and a local name in a well isolated context, and a wiring table to glue these together (using the URIs) that's all you need.
Consider the following case: One of my applications use a repository block, and this repository block has a db connection with name and password as deplyment parameters. If another application need to use the same repository block, but connected to another db it will have other deployment parameters. In this case we will have two deployed instances of the same block with different deployment parameters. How do we differ between them.
Another case is if we follow the method of handling the profile info for a portal block that Reinhard proposed. If we want to use two portals under the same Cocoon the portal block will be deployed in two instances with different implementations of the profile contract. Also here is the question is how we differ between the two instances.
With declaring it, do you mean that we have a block deployment descriptor that is connected to the main sitemap?Well, no. The BlockManager has block 'scopes' and should allow a block to resolve only the blocks that it explicitly depended upon and for which it has a name for. The rest is just like it wasn't there... and this is required to avoid polymorphism without unwanted collisions.</comment>
Interesting enough, IIUC, blocks are only accessible through the block protocol from other blocks,
No; IMHO they are all available through BlocksManager.
They are, but AFAICS they have no common short name that could be used outside blocks, and it is the short name that is used by the block protocol.
Exactly.
This could be solved by considering the main sitemap being part of a block as well and have a (possibly optional) block descriptor for it. Then the blocks would have a short name from the main sitemap as well.
YAGNI: if you need a block, declare that you need it and associate a name with it. Otherwise, you don't need it, you don't have access to it.
/Daniel
