cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vadim Gritsenko <>
Subject Re: [RT] The block protocol
Date Tue, 05 Apr 2005 12:40:07 GMT
Daniel Fagerstrom wrote:
> 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 
> ( 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 ->
> 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 

> 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.


>>> resolves it by looking up "skin" in the wiring info for the block 
>>> ( and find the mapping:
>>>   skin ->

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 
>>> "" 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, 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.


View raw message