>1. When I return a window to the pool who is responsible for the 
>cleanup? The class the uses it should return it clean or somehow its 
>cleaned magically during pooling?

When you no longer need the pool any more (e.g. When the application finishes) 
you could destroy all objects in the pool; OTOH, this is typically when the 
user navigates away form the page so you could do nothing and let the browser 
take take of it for you.

>2. What about event listeners? For example in this classic demo
>http://tinyurl.com/3grnpn4 if we want to use pooling for the button, 
>should we somehow remove the event listener before returning it to the 
>pool or it doesn't matter?

If it’s a general purpose, global pool then you would typically remove event 
listeners before the object goes back into the pool because the event handlers 
will remain attached and when you reuse the object and attach new listeners 
then both the old and the new listeners will be executed.  But it depends on 
what your application expects, e.g. if your pool is specialised to contains 
objects which _always_ have a given set of event listeners attached then your 
app would know not to add extra listeners.

>3. Let's say we have a win = qx.ui.window.Window() object that contains
>controls taken from the pool. In the win.destruct() we write code that 
>returns containing widgets to the pool. When we call win.destroy() it 
>will call this destructor and then will dispose the win object. What if 
>we simply return that object to the pool. Is there any way to call the 
>destruct() function?

You would have to write code that removed the widgets from the window and put 
them in the pool before the Window has disposed them, ie making sure that what 
is in your pool has never been disposed.  If you later decide you don’t want 
the widgets, you would dispose the pool (in which case the pool calls each 
widgets dispose() method).  You must not dispose anything more than once, or 
continue to use a widget after it has been disposed.

>4. I am thinking of creating a singleton class subclassed from
>qx.util.ObjectPool and use that as a pool for all my code. Is this a 
>good practice or there are big dissadvantages?

That’s fine, it’s down to your application design - once the ObjectPool has hit 
its size limit for a given class of objects it will not allow any new ones to 
be added (it just disposes of new ones straight away) so you might find that a 
specific part of your application would benefit in a specialised pool.

However, have you identified parts of your app that would really benefit from 
object pooling?  My understanding is that this technique was really, really 
useful in older browsers like IE6 to avoid some really bad performance issues 
related to memory, garbage collection, and DOM but in modern browsers is much 
less of a problem; I am sceptical that the app would benefit at all from using 
object pooling in the general case.

John





------------------------------------------------------------------------------
_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

Reply via email to