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 Tue, 05 Apr 2005 08:49:21 GMT
Vadim Gritsenko wrote:

> Daniel Fagerstrom wrote:
>>                             --- o0o ---
> </lurk>
> Just some sidenotes...
>> The main involved components are the BlocksManager that in turn has 
>> access to one BlockManager for each block.
> (From [1] BlockManager is the ServiceManager of the block)

Yes it is. We need to discuss the details about component managment in 
blocks also. My mail was only about the block protocol aspect of the 

>> Block local access
>> ------------------
>> Each BlockManager has its own SourceResolver and especially it can 
>> have its own implementation of the block protocol which is registred 
>> with the scheme "block:".
>> An absolute URI relative to the root sitemap of the block looks like:
>>   block:/foo/bar
>> and is a hierarchical URI. It is invoked by first trying "foo/bar" in 
>> the current block's root sitemap and if that fails 
>> "block:super:/foo/bar" is invoked.
> You don't need that. As mentioned in [1], local BlockManager has 
> access to the parent BlockManager, so local BlockSource instance will 
> lookup parent BlockSource and delegate to it. (Or may be this is just 
> another way of saying the same? Hm.)

I think we mean the same.

>> More about "block:super:" later. To make this work I would assume 
>> that error handling must work a little bit different in blocks so 
>> that a sitemap can fail without emmiting any error messages immediatly.
> That's the only behaviour available in 2.1.6 and below.


>> In the case when a block A has invoked an URI in its super block B, 
>> to achieve polymorphism, all block protocoll resolution in B must be 
>> done by first asking A's block resolver before trying its own.
> So it means local SourceResolver (or it's settings) should be 
> preserved for the duration of polymorphic source processing.


>> A relative URI in a sub sitemap "/foo" from the block's root sitemap,
>>   block:./bar
>> (an opaque URI) is resolved to
>>   block:/foo/bar
>> using the same method as Pier used for the cocoon protocol in his Wiki.
>> 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. 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.

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.

>> resolves it by looking up "skin" in the wiring info for the block 
>> ( and find the mapping:
>>   skin ->
> 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.

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

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

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.

>> as the short name, "skin" e.g., only exists in the block wiring info. 
>> Are we going to consider the main sitemap part of a block as well to 
>> be able to access blocks from it?
> (I did not get this question).

Is it clearer from my explanations above.

>> Next the block manager asks the blocks manager for the URI,
> Nope. No need - it can simply ask for BlockManager.
>> this could be done through a "blocks:" protocol that is connected to 
>> the blocks manager. The uri "block:skin:/foo/bar" could be resolved 
>> to e.g.:
>>   blocks:{}:/foo/bar
>> Besides that it looks awfull I would doubt that it even is synatactic 
>> correct as an opaque URI. I only wrote it down to provoke you to find 
>> something better ;)
> IMHO, it (BlockManager) does not need URI of another block, at all. So 
> no need for writing awful URIs :-P

See above.

>> Next the blocks manager looks up the block manager identified by 
>> "" and send the URI:
>>   block:/foo/bar
>> to it, which will be resolved by the skin blocks internal 
>> implementation of the block protocol.
> Yep.
>>   block:super:/foo/bar
>> is resolved in the same way as an ordinary external block URI. To 
>> make this possible the role of being a super block must be 
>> identifiable among the connections in the wiring info. Maybe by 
>> reserving the name "super" for this case.
>> WDYT?
>> /Daniel
> Vadim
> <lurk>
> [1]


View raw message