cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <dani...@nada.kth.se>
Subject Re: Multiple block instances
Date Wed, 06 Apr 2005 11:54:19 GMT
Reinhard Poetz wrote:

> Daniel Fagerstrom wrote:
>
>>>> 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 ;)
>
>
> It should be as simple as writing a new block.xml and make a .cob out 
> of it. btw, I heard of some project called Lepido .... ;-)
>
> After reading your mail I thought a bit about block instances but IMO 
> they make things more difficult: where to put the 'constructor 
> parameters', URI resolving and maybe more stuff.

In my view there is nearly no extra difficulty. The BlockManager 
represents an instance and the deployment parameters and connections are 
the constructor parameters. The only differnce is that a identifier is 
generated at deploy time so that several BlockManagers can represent the 
same Block but with different parameter and connection values.

> Maybe we really need them but this will be clearified after we set up 
> some usecases using a working prototype.

Sure, it will only affect the identifier in the wiring and some 
fuctionality in the deployer. For the communication between the 
BlockManager and the BlocksManager it shouldn't matter. So its no big 
deal to change it when we see that we need it ;)

/Daniel


Mime
View raw message