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