Daniel Fagerstrom wrote:
You probably meant here "BlocksManager"
No I meant BlockManager. In my discussion I assumed that a BlockManager is responsible for the information within a block element in the wiring (http://wiki.apache.org/cocoon/BlocksWiring) and that the BlocksManager "correspond" to the blocks element. So from this the BlocksManager only know the URI that identifies the block. The mapping from a short name to the URI
skin -> http://mycompany.com/skins/corporate/34.3.345
is only known localy whithin a BlockManager. The situation is AFAIU analoguos with the relation between a namespace URI and a namespace prefix. Where the URI is a universal identifier and the prefix works as a identifier within the document. In the same way the blocks URI is a universal identifier of the block while the short name only identifies it whithin a certain block and the wiring for the block is like a namespace declaration. Different blocks can access the same block with different short names.
This is correct.
I think this design is necessary for achieving scalability. If the short name was assumed to be unique, we would get name clashes between external blocks developers.
Absolutely: URI gets prefixed and are used only in the local wiring context, they lose meaning if detached from the block that uses them.
Also because the "using" block is responsible for this mapping:
[ http://host/myBlock/3.4.34 -(requires)-> http://blah/skin/2.3 ] --(calls it)--> "skin"
so, block:skin: used inside http://host/myBlock/3.4.34 will point to whatever http://blah/skin/2.3 implementation you decided to wire it to, but block:skin: used somewhere might route somewhere else.
So, "skin" has no absolute meaning, just local and it's still a solid contract because it's defined by the requiring block, which is the only one using and in-control-of that name.
resolves it by looking up "skin" in the wiring info for the block (http://wiki.apache.org/cocoon/BlocksWiring) and find the mapping:
skin -> http://mycompany.com/skins/corporate/34.3.345
Beside mapping, BlocksManager can fetch an instance of the referenced Block, i.e. its BlockManager. Not sure if URI by itself is needed at all.
The BlockManagers could be wired to get direct access to each other during start up. In that case we don't need a global identifier during execution. I prefered to make all communication between the blocks proxied by the BlocksManager in the interest of isolation. But it is more of an implementation detail. Isolation can be achieved in other ways.
You don't need global block identifiers other than their URIs (which are meant to be 'globally' unique, not just locally).
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.
</comment>
Interesting enough, IIUC, blocks are only accessible through the block protocol from other blocks,
No; IMHO they are all available through BlocksManager.
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.
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.
-- Stefano.
