cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: [RT] The block protocol
Date Tue, 05 Apr 2005 16:48:38 GMT
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.


Mime
View raw message