(New page: Web browser applications are quite sensible to memory leak. Actually, there is a set of well known coding patterns that cause leak. V3 will provide several features to avoid matching such ...) |
|||
| Line 1: | Line 1: | ||
| + | (Draft) | ||
| + | |||
Web browser applications are quite sensible to memory leak. Actually, there is a set of well known coding patterns that cause leak. V3 will provide several features to avoid matching such patterns. | Web browser applications are quite sensible to memory leak. Actually, there is a set of well known coding patterns that cause leak. V3 will provide several features to avoid matching such patterns. | ||
== DOM Abstraction == | == DOM Abstraction == | ||
| − | Our API provides a [[ | + | Our API provides a [[FCKeditor 3.x/Design and Architecture/DOM Abstraction|DOM abstraction]] set of classes to manage DOM objects. Memory leak free is the most important benefit of it. |
It means that we are able to use the API in any situation, including within well known leakage patterns, and we'll be sure that no leak will happen. The DOM abstraction classes will be the only point of the code dealing with DOM elements, so we can concentrate all our leak free efforts in this set of classes only. | It means that we are able to use the API in any situation, including within well known leakage patterns, and we'll be sure that no leak will happen. The DOM abstraction classes will be the only point of the code dealing with DOM elements, so we can concentrate all our leak free efforts in this set of classes only. | ||
Revision as of 13:53, 20 February 2008
(Draft)
Web browser applications are quite sensible to memory leak. Actually, there is a set of well known coding patterns that cause leak. V3 will provide several features to avoid matching such patterns.
DOM Abstraction
Our API provides a DOM abstraction set of classes to manage DOM objects. Memory leak free is the most important benefit of it.
It means that we are able to use the API in any situation, including within well known leakage patterns, and we'll be sure that no leak will happen. The DOM abstraction classes will be the only point of the code dealing with DOM elements, so we can concentrate all our leak free efforts in this set of classes only.
No Cross References (DOM x JS)
The most relevant leak patterns are related to cross references set between DOM objects and JavaScript objects. There are several ways to achieve it, but the result is that you end up with a JavaScript object that has a property pointing to a DOM element that has a property pointing back to the same JavaScript object (even indirectly).
The solution implemented by the DOM Abstraction classes is that we have references in one direction only: JavaScript objects that point to DOM elements. The opposite will never happen.
Expandos Handling
To avoid having references to JavaScript objects inside DOM objects, we should avoid setting the so called expando properties, thus JavaScript properties not native to the DOM.
But, at the same time, expandos are quite useful, as they can be used to append further information, or back references in the DOM element itself, so those properties can be used later in the code execution.
To have the expandos flexibility, avoiding leakage, we'll provide a specific function to set and get expando properties. Internally, this function will simply set an integer key in a single expando property in the DOM object. That key can be used to retrieve an item from an internal array, which contains all expandos set to that DOM object. So, in the DOM object, we'll have this one and only expando containing an integer value, which doesn’t happen to cause leaks.