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 16:51:41 GMT
Stefano Mazzocchi wrote:

> Daniel Fagerstrom wrote:
>> Stefano Mazzocchi wrote:
>>> 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.
> Context.
> Here is your problem:
>  [ Block A -(requires)-> Block C ] -(named)-> 'database'
>  [ Block B -(requires)-> Block C ] -(named)-> 'database'
> this is the 'structure' of the dependency, not your actual instance.
> When you install Block A, the block deployer (thanks Reinhard for 
> correcting me) will look for Block C (let's not dicuss the 'how' of 
> this now).
> The block will be fetched, unpacked, configured and wired. At this 
> point, Block C will become known (to A!) as "database" and from the 
> block A, you can call "block:database:/" and that *instance* of block 
> C will respond.
> Note that since java classloading is already namespaced, you *DO NOT* 
> need to provide a block hint for the classloading: if Block C provides 
> a class called
>  org.myhost.myapp.myblock.Database
> you flowscript in block A can call
>  cocoon.getComponent("org.myhost.myapp.myblock.Database")
> and obtain that *instance*, configured as you wanted at installation 
> time (here, you will be asked for username/password/jdbc-url etc.).
> Now, later on, you install Block B, which requires an instance of 
> Block C. You already have one installed, so the block deployer will 
> ask you if you want to reuse that instance or another one.
> at this point, if you want to use another instance (keep the code, but 
> change the behavior thru different configurations!), the block manager 
> (and its internal classloader and sitemap mounter) will make sure that 
> if you call block:database:/ from block B, you end up in *another* 
> instance, with different configurations and different parameters.
Yes, sounds good.


View raw message