cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: [RT] The block protocol
Date Wed, 06 Apr 2005 07:57:55 GMT
Stefano Mazzocchi wrote:

> Daniel Fagerstrom wrote:


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

>>>> </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.
With declaring it, do you mean that we have a block deployment 
descriptor that is connected to the main sitemap?


View raw message