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 01:15:05 GMT
Daniel Fagerstrom wrote:
>                             --- o0o ---

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)

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

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

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

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

> </comment>
> Interesting enough, IIUC, blocks are only accessible through the block 
> protocol from other blocks,

No; IMHO they are all available through BlocksManager.

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

> 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

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


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



View raw message