Introduction to the DOM parser

Introduction

XML is considered as being the next important stage in the evolution of the Web. A universal Web exchange format, recommended by the W3C, many standards are now based around XML, so as to facilitate data sharing at a lesser cost.

Objecteering incorporates an XML parser which can be accessed through J programming via a DOM (Document Object Model) API, whose functioning will be presented in this chapter.

A model dedicated to use of the parser

In order to implement the parser from J, you must be familiar with the simplified model providing access to the DOM API of the XML parser. Figure 21 presents a class diagram of this model.

Figure 21. Class diagram of the DOM API providing access to the XML parser

Why a simplified model?

Most DOM objects (Attributes, Texts, Comments…) do not provide services different enough from those of a node to justify their existence as separate objects. This means that these types of element can be created from the JDOM_Document (createAttribute(), createComment()…) class, whilst retrieving JDOM_Nodes and not JDOM_Attributes or JDOM_Comments. This does not affect the DOM possibilities of our API.

To illustrate the dynamics of parser use, Figure 22 shows a sequence diagram of API use.

Note: To use this model, a J session must be open.

Figure 22. Sequence diagram illustrating the use of the API

Memory management

With the exception of JDOM_Document instances, JDOM_Node, JDOM_Parser or JDOM_Element type objects are destroyed at the end of a J session, without intervention on the part of the developer. This makes it important to indicate the reasons for this choice and their implications on the functioning of J programs.

Objects available in J are only proxies to real underlying DOM parser object. These objects, instantiated when an XML file is read or when element creation methods are called from the DOM API provided, are only destroyed when their reference counters return to zero. This means that the destruction of a JDOM_Node element in J does not destroy the associated DOM element, as long as another JDOM_[...] object references it.

To lighten Objecteering's memory load, several objects are automatically destroyed at the end of a J session. This allows the JDOM tree to be destroyed without destroying the underlying DOM tree, and provides the possibility of adding the document to the user data contained in a non-modal dialog box (a window which exists after the end of a J session).

This allows you to access tree elements during the life of the dialog box, but implies the risk of not being able to free up the entire tree if destruction is forgotten.

The memory management rule is, therefore, as follows:

A JDOM_Node, JDOM_Parser or JDOM_Element object must never be saved in a non-modal dialog box, as these objects are destroyed at the end of a J session.

The desired JDOM_Document(s) must be attached to the non-modal dialog boxes and destroyed when these dialog boxes are destroyed, or destroyed manually before the end of the J session, if you only wish to handle documents locally.