Vadim Gritsenko wrote:
Daniel Fagerstrom wrote:
Inter block access ------------------
An URI to another block "skin" e.g. looks like:
block:skin:/foo/bar
the BlockManager
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.
Yes, you are right. See my prev email about portal / profile block: portal knows which profile it wants (URI), and BlocksManager can resolve block instance using URI.
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.
Yep
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
Now we are on the same page. So BlockManager (or something else on its behalf - like Wiring) looks up URI by the short name.
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.
Yes, once URI known, BlockManager should ask for other block instance from BlocksManager (which might be as simple as this.manager.lookup()).
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.
Yes, my recall was wrong :-)
</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.
Which is resolved to URI which can be used to get a block from BlocksManager as described above.
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.
I thought about it... If there is a root block, then there will be *no* root sitemap. As I see it, either you deploy root block (new behaviour), or you have root sitemap (old one) which then can mount blocks as needed.
Vadim
