| (3 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
| + | (Draft) | ||
| + | |||
The V3 API core code will include a rich set of classes to manipulate the DOM. Actually, all DOM interactions in the entire codebase will be done through these classes "exclusively". | The V3 API core code will include a rich set of classes to manipulate the DOM. Actually, all DOM interactions in the entire codebase will be done through these classes "exclusively". | ||
| − | For each of the basic DOM objects, we'll have a dedicated class, including: window, document, element | + | For each of the basic DOM objects, we'll have a dedicated class, including: window, document, element, text node and event. Those are the typical objects used by our application. |
The following example demonstrates what we mean with DOM abstraction: | The following example demonstrates what we mean with DOM abstraction: | ||
| Line 21: | Line 23: | ||
// Set the inner HTML for the first child element of body. | // Set the inner HTML for the first child element of body. | ||
doc.getBody().getFirstChild().setInnerHtml('');</pre> | doc.getBody().getFirstChild().setInnerHtml('');</pre> | ||
| − | |||
== Benefits == | == Benefits == | ||
* Rich and easy to use API. | * Rich and easy to use API. | ||
* Consistency among all browsers. | * Consistency among all browsers. | ||
| − | * Memory leak free code. | + | * [[FCKeditor 3.x/Design and Architecture/Memory Leak|Memory leak free]] code. |
== Performance == | == Performance == | ||
| − | A simple test page has been created to measure the performance impact of using a simple DOM abstraction set of classes, instead of direct DOM calls. | + | A [[FCKeditor 3.x/Design and Architecture/DOM Abstraction/TestDomAbstraction.html|simple test page]] has been created to measure the performance impact of using a simple DOM abstraction set of classes, instead of direct DOM calls. |
The following are the test results (in ms) in a Pentium 4 2GHz. The first value is the DOM abstraction results, while the second is the native times: | The following are the test results (in ms) in a Pentium 4 2GHz. The first value is the DOM abstraction results, while the second is the native times: | ||
Latest revision as of 09:58, 28 February 2008
(Draft)
The V3 API core code will include a rich set of classes to manipulate the DOM. Actually, all DOM interactions in the entire codebase will be done through these classes "exclusively".
For each of the basic DOM objects, we'll have a dedicated class, including: window, document, element, text node and event. Those are the typical objects used by our application.
The following example demonstrates what we mean with DOM abstraction:
// Create and element object based on its ID.
var element = new Element( "element_id" );
// Get the element name (always lowercase).
element.getName();
// Get next sibling node.
element.getNext();
// Set the class attribute.
element.setAttribute( 'class', 'myClass' );
// Get the element document (instance of our Document class)
var doc = element.getDocument();
// Set the inner HTML for the first child element of body.
doc.getBody().getFirstChild().setInnerHtml('');
Benefits
- Rich and easy to use API.
- Consistency among all browsers.
- Memory leak free code.
Performance
A simple test page has been created to measure the performance impact of using a simple DOM abstraction set of classes, instead of direct DOM calls.
The following are the test results (in ms) in a Pentium 4 2GHz. The first value is the DOM abstraction results, while the second is the native times:
- IE : 1051 / 541
- Firefox : 921 / 561
- Safari : 200 / 90
So we can note a performance degradation in a factor between 2 and 3 times over the native DOM.
But, we can also take in consideration that this test executes 1.000 calls to a function that does around 10 DOM specific calls. So, we have potentially 10.000 calls being executed. So, the real impact we could have by using the DOM abstraction classes is definitely inferior to the benefits we have with it.