Mnemonic C++ library for DOM (lib-dom)
General Info

Introduction
Screenshots
Mailing Lists and IRC
Alternative Browsers
Special Thanks

FAQ
Understanding Mnemonic
TODO list and ideas
Bug Reports


User Info

Download binaries
Platforms
Compiling Mnemonic
Other useful software


Developer Info

Core
Message modules
Library modules
Object modules
Coding Guidelines
Browse Source
Using CVS


View with any browser

Website questions to:
webmaster@mnemonic.org

Mnemonic questions to:
disc@mnemonic.org

 

Overview

The lib-dom is a C++ library implementing the w3c Document Object Model. That is, it contains the classes necessary to store a document tree and provides the DOM methods to manipulate it. All of level 1 and most of level 2 will be supported. It is, however, purely C++; a CORBA wrapper can easily be written on top of this library when required since almost all interfaces and methods follow the DOM recommendation.

There is also support for storage of CSS stylesheets, but we do not follow the DOM here. For all practical purposes, the CSS 2 DOM working draft is completely useless and braindead.

The DOM specification uses a rather old-fashioned (at least when compared to the C++ STL) way of addressing containers. Wherever possible, faster and more efficient C++ interfaces, which can be fed to the standard STL algorithms, have been provided in lib-dom as well. Some of them are based on the preliminary DOM level 2 specifications. All of the DOM standard access methods are however present and can be used at the same time.

All parts of the DOM that are tagged as `deprecated' have not been implemented. (some of those things are really stupid, like those zillions of HTMLElement descendants).

All names are 100% identical to the DOM specification. The entire library is placed in the namespace `DOM' to avoid name clashes with other libraries.

The CSS part of the DOM level 2 working draft is completely useless for our purposes (it requires a CSS parser to be present behind almost all interfaces, for example). The implementation in lib-dom therefore differs quite a bit from the DOM level 2 working draft.

Warning: the DOM level 2 specification is in a miserable state right now. Not even iterators are designed right. Things will change, hopefully.

Cascading Style Sheets

The css part of lib-dom serves two purposes. Firstly it provides a convenient way to store the CSS rules internally, and secondly it provides methods to determine, for any node in a DOM::Document tree, all the CSS properties.

As the rules which determine the particular effect of a CSS property on a given DOM element are rather complicated (and differ a lot between various properties), all CSS2 properties are hardcoded in the library. On the positive side, this means that you can lookup a property using an enum as identifier rather than the entire string, which increases the lookup speed.

It is up to the user of the implementation to decide whether properties that should be inherited by child elements are stored in the children as well, or whether a layout tree is used that can refer to parent elements for these properties. The lib-dom is able to serve both needs, as it returns both the actual property value as well as an indicator of whether the property is inherited or specified on the particular element. /* More grumbling follows. @media : This is EXTREMELY stupid. It is not even a proper rule, since the declaration block is a stylesheet by itself. Can't these people see that `media' is just something that should be attached to an entire sheet? @page : Why can't this just be a set of properties on <BODY>, like page-size: page-margin: Or on <HTML> if you want. This does not make sense AT ALL. O well, we'll just make this a pseudo-class. (so we'll get . : # and @ as class/pseudoclass/id/atrule. @font-face : Must be a Micro$oft invention. This is sooooo pathetic. For any serious work it is useless. Again, we will store this as an atrule thingy. */

Tree structure

    node--+
     |    | firstChild
     |    +----->-------node
     |    |               |   
     |    |               V   nextSibling
     |    |               |
     |    +-------------node
     |    |               |
     |    |               V   nextSibling
     |    | lastChild     |
     |    +----->-------node--+
     |                        |   firstChild
     V nextSibling            +------>--------node
     |                        .
     |                        .
    node--+
     |    | firstChild
     |    +----->-------node
     |    |               |   
     |    |               V   nextSibling
     |    |               |
     |    +-------------node
     .
     .

Memory management and node owners

As long as a Node is not inserted in the Document tree, you are responsible for its memory management. However, as soon as it is inserted, you can forget about the pointer; destruction of the entire Document or a part of it which contains the given Node will automatically delete the it. If you call removeChild or replaceChild, deletion of the Node that is returned is again no longer the responsibility of Document.

The basic reason for the above logic is that the Document that created the Node does not have pointers to it as long as it is not inserted in the tree.

Remarks on unimplemented features

This section contains a few remarks on unimplemented parts of DOM that can be done in a more elegant way using mnemonic-core.

Level 2 defines events. These are basically just messages for mnemonic. There are several types, normal events, UI events and mutation events. These will be mapped to mnemonic messages, see the msg-dom module. The level 2 draft does not address priority issues at the moment.