cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Giacomo Pati <>
Subject Re: Doing our own cleaning up.
Date Tue, 19 Sep 2000 21:37:51 GMT
Berin Loritsch wrote:
> > ** Original Subject: RE: Doing our own cleaning up.
> > ** Original Sender: Paul Russell <>
> > ** Original Date: 19 Sep 2000 17:18:30 -0000
> > ** Original Message follows... 
> >
> > Hi All,
> > 
> > Therefore, do we need an equivalent of Composer and ComponentManager
> > for Poolable components? Thoughts/flames/comments?

The SitemapComponents in C2 can have all sorts of interfaces
implemented. There are Poolable, Sharable and none at all in addition to
the usual interfaces like Configurable and Composer. This cries for a
specialized CM to handle all that kind of Components at least for C2. 

In the Avalon list you talked about that a CM should return a Class and
this is for my purpose not acceptable. I need instantiated objects
wether new ones or already instatiated ones because they are Sharable
(thread safe) or Poolable (Recyclable).

> You can make a Pool into a Component, and get your stuff that way...
> In the Avalon list we are working on a standard way to access Components
> in two dimensions, and the Pool can work behind the scenes with that.

That is the way I will do it for the SitemapCM I'm writing. I have other
needs as well for that. ie. can be hierachically structured to give a
sub SitemapCM a parent one to ask for components it does not manage
(some kind of inheritance)

> We're not done discussing it of course....

Maybe you can take these issues (which I've placed on the Avalon list
already) into mind for the remaining discussion about CM :)


PWR GmbH, Organisation & Entwicklung      Tel:   +41 (0)1  856 2202
Giacomo Pati, CTO/CEO                     Fax:   +41 (0)1  856 2201
Hintereichenstrasse 7                     Mobil: +41 (0)78 759 7703
CH-8166 Niederweningen          

View raw message