XML documents are represented at run-time by a logical structure called a Document Object Model or DOM. Elements within XML documents are represented by instances of classes that implement the DOM Interface org.w3c.dom.Element. Basic element implementation classes are typically provided by XML parser implementations.

Although an XML parser has some knowledge about the syntax of elements, it knows nothing about what the elements mean. The task of imparting semantics to elements is left to applications or specialized frameworks that often use a standard parser to build the DOM from an XML document.

eNode Object Realizer uses an off-the-shelf XML parser to build a DOM for each document, but it provides its own element implementation classes to represent elements in the DOM. Thus, there are classes that represent element types such as label, panel, and so on. These element implementation classes are standards-compliant to the extent that they also implement the org.w3c.dom.Element interface. However, you will rarely, if ever, need to interface with these element implementation classes. Instead, you will directly access and manipulate the realized form of an element, also known as its core.

Object realization causes an element to manifest its core in a form dictated by a class that implements the element’s core functionality. Whenever possible, elements are mapped directly to standard classes in the Java™ Runtime Environment (JRE) for their core functionality.

For example, the core, or realized form, of a label element is an instance of javax.swing.JLabel, and that of a panel element is an instance of javax.swing.JPanel. This has the dual benefit of giving you an interface that you may already be familiar with, while keeping the footprint of the framework down to a manageable size. However, you are not required to stick to these default mappings — You may choose to realize an element with a different core class.

The standard Java core classes are exceptionally well-designed, and can be used as-is for most purposes. However, you will inevitably find yourself in situations where you would like to extend these classes to do something different. You can instruct the object realizer to use a custom class for an element’s core simply by specifying the name of the class in the class attribute for an element.

Support for the class attribute is pervasive, allowing you to override core classes for most element types on a per element basis. Of course, the user-defined classes must be API-compatible with the default class used for each element type. Consult the reference to see the mapping of each element to its default core class.

The following example uses a custom class to realize the label element, as seen by its class attribute.

Make this object in eNode Sandbox. The result should be similar to the following:

Note that the markup in this example deals exclusively with presentation, and contains no information about the label’s title — The title is supplied at run time by the class com.enode.xalt.examples.DateLabel, whose listing is shown below.

While the above example is a little trite, it illustrates a very powerful feature. The ability to specify the name of an arbitrary class directly in the markup for an element allows you to plug in custom classes for models of lists, tables, trees, and so on, that get their data at run time using SOAP, RMI, or even direct JDBC calls.

The alternative, of course, is to dynamically generate the markup on an application server that folds in the results of computations and queries into XML documents on the server. In that case, the server has to do most of the work — The client simply interprets the presentational markup without doing any real computational work.

Read our white papers that discuss this issue from a usability perspective.