You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Reinhard Poetz <re...@apache.org> on 2005/04/06 10:41:36 UTC
Multiple block instances
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).
>
> 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.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: Multiple block instances
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
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
Re: Multiple block instances
Posted by Reinhard Poetz <re...@apache.org>.
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. Maybe we really need them but this will be clearified
after we set up some usecases using a working prototype.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: Multiple block instances
Posted by Ralph Goers <Ra...@dslextreme.com>.
Daniel Fagerstrom wrote:
> 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.
This depends on whether the Java class is a singleton, in which case the
constructor is called only when the class is instantiated the first
time. The same could be true for blocks as well, if that is desirable.
It probably would be more manaageable if the first release required that
blocks be singletons and then expand that later if needed. Isn't that
basically the way servlets work?
>
>
> --- o0o ---
>
> I guess that in your view there is no istantiation, you subclass and
> have everything "static" instead.
Being a singleton doesn't mean that you can't have some initialization.
>
> Both views will solve the same problem but in different ways. With
> your view we might want to have tool support for automatic subclassing ;)
>
> /Daniel
>
Re: Multiple block instances
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
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.
ok.
> (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 ;)
/Daniel