>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