cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vadim Gritsenko <va...@reverycodes.com>
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 
> (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


Mime
View raw message