cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: Multiple block instances
Date Wed, 06 Apr 2005 11:24:29 GMT
Reinhard Poetz wrote:

> Daniel Fagerstrom wrote:
>> 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.
> If you need different behaviour of one block you will have to extend 
> it (so it gets another unique ID) and only change the properties in 
> block.xml.


> (Although I think that this isn't a good example because it's not a 
> consuming block's concern to set the database connection IMO).

Didn't suggest that. What I described above was supposed to happen at 
deploy time. The two applications only know that they talk with a block 
that fullfills the repository contract.

>> Another case is if we follow the method of handling the profile info 
>> for a portal block that Reinhard proposed. If we want to use two 
>> portals under the same Cocoon the portal block will be deployed in 
>> two instances with different implementations of the profile contract. 
>> Also here is the question is how we differ between the two instances.
> Let's assume that you want to deploy two custom blocks that are based 
> on the portal block. Doing so leds to two different blocks (--> 
> different block IDs) which both extend the same block. Both blocks can 
> use the same profile block to be customized or each gets its own - 
> depends on your requirements.

If we compare the situation with concepts from Java, my view was:

Java: You download a class with unique combination of name and namespace.
Blocks: You download a block with a unique URI.

Java: You call the constuctor of the class possibly with parameters and 
get an object with an unique object id.
Blocks: You deploy the block and get a block instance with a unique (in 
your Cocoon) block instance id. During deployment you give it parameter 
values and connect it to other block instances.

                                     --- o0o ---

I guess that in your view there is no istantiation, you subclass and 
have everything "static" instead.

Both views will solve the same problem but in different ways. With your 
view we might want to have tool support for automatic subclassing ;)


View raw message