XUL Tools and What They Mean
Pages: 1, 2, 3
Widgets
Widgets are the pieces that you assemble to make an interface. Menus, toolbars, buttons, and scrollbars are widgets, and so are such general-purpose pieces as boxes and springs. These widgets can be created and placed within a XUL file as simple elements: <menu>, <toolbar>, and so on. The syntax for these elements is based for the most part on XML. Collectively, these widgets are also knowns as the XPToolkit.
Object Models: DOM and AOM
The Document Object Model (DOM) is the representation of a document as a series of scriptable objects. When a scripting language like JavaScript accesses various parts of an HTML document, it does so by means of the DOM. The parts of the document, such as the head, the links, the body, any tags, are available as nodes whose attributes can be gotten and set. There are, unfortunately, different document object models corresponding to different types of documents and also to different proprietary notions about what in a document should be exposed programmatically. The W3C has standardized on a particular Document Object Model and already has a candidate recommendation for an updated version. This is the DOM that is reflected in XUL and in the Mozilla browser. At the highest level in the DOM tree of nodes sits the window object itself. The window has child nodes like the document itself, a history object which records the pages a user has seen, frame nodes, and so on, all of which are accessible programmatically.
With the dramatic improvements in the object model and the power of the W3C DOM2, the concept of the DOM is displacing that of the more abstact DHTML. Since any dynamic web development is dependent upon programmatic access to the web document (or XUL interface), and since the DOM is a standard and earlier notions of Dynamic HTML were not, the term "DOM" is used as a synonym for or instead of terms like "Dynamic HTML" or "DHTML."
The AOM stands for the Application Object Model, and is an extension of the DOM up into the interface defined in XUL. Just as HTML is reflected in the DOM as nodes like link, layer, and img, XUL is reflected in the Application Object Model in the hierarchy of XUL widgets: browser, menu, menu item, and so on. The DOM and the AOM form a kind of continuum, the whole of which is manipulable from the standards upon which XUL is based.
Near Synonyms for XUL
There is much confusion about the acronyms that begin with "X" in the Mozilla Open Source Project. The moz architecture item down below describes XPCOM, XPIDL, and XPConnect, three somewhat related technologies for getting access to application code from the interface. This section describes XUL, XPToolkit, and XPFE, which are in some respects synonymous and in others quite different.
In briefest terms, XUL is the XML-based language used for creating interfaces, XPToolkit is the set of XUL widgets (such as menus and toolbars) actually assembed for this purpose -- the building blocks of the interface -- and XPFE, the Cross Platform Front End, is the front end that has been created from XPToolkit.
The differences here are significant: XUL is the universe of elements, attributes, syntax, rules, and relationships, while XPToolkit is really the finite set of interface-specific elements created in XUL. The XPFE is what's been created out of the XPToolkit. A loosely analogous relationship might be that XUL, XPToolkit, and XPFE are to one another what HTML, the actual HTML tags, and an HTML web page are to one another, respectively.
XUL Parts
People sometimes get confused about the syntax for describing the parts of a widget. For a widget like the menu that appears in the following example, menu is the element and both value and the ID are attributes.
<menu id="file" value="File">
<popup>
<menuitem value="New" onclick="CreateNewDoc()" />
<menuitem value="Open" onclick="OpenDoc()" />
<menuitem value="Close" onclick="CloseDoc()" />
</popup>
</menu>Element names the item, the widget, while attributes describes features of that element, such as its name, its style, and so on. In object-oriented parlance, the element is analogous to the object itself while the attribute is like a property. The attribute has a value associated with it (such as the string "file" for the ID attribute in the example above). Note that the menu element includes both the opening tag at the top and the closing tag at the bottom of the example. In a way, the menu element comprises the menu element itself and its children, the popup and menu items.
Events
Events are also a source of confusion for many less-hardened developers. In fact, I'm not sure I understand them adequately myself, but here goes a simple explanation of events and of how they are used, basically, in a event-based interface like those created in XUL. Events are messages that are sent from an object when that object performs some action. For example, A document fires, or raises, the "load" event when it is loaded into a browser. The "click" event is fired by a button when it is clicked.
If you don't do anything about these events, then you probably never know about them. Documents will load, buttons will be clicked, and links will be hovered over, and events will be raised for all these actions behind closed doors. If, however, you write event handlers inside event listeners, as we will describe shortly, you can use these events to set off other actions. This using of events to prompt other, more expicit actions is loosely what is meant by an event model.
Where, exactly, are these events fired? Fired at whom? Events that are fired by an object "bubble up" the hierarchical model that is the DOM (or the AOM) node by node. These events can be "handled" at any point in that hierarchy -- including in the same node in which they were raised. If no one at a particular level in the hierarchy is interested in the event, then the event bubbles up to the next highest level on out to the top of the hierarchy.
The term isn't used very often, but an "event listener" is a special attribute of an object that listens to its own events. The document, for example, has an "onload" event listener to listen for its "load" event. XUL buttons have "onclick" event listeners. The event listener is really a convenience; instead of using it, you could find out when an object fired an event, then go find out what that event was, and then write some event handling code as a response to that event, but the event listener provides an easy mechanism for writing event handlers for specific, common events.
An event handler is a snippet of code that you write in response to an event. An "onload" event handler says, in effect, when this document loads, I want to this to happen. And the event listener attribute provides a very convenient place in which to write event handlers -- so convenient, in fact, that the term event handler is often used to describe both the event listener attribute and the event handler code you write within it. To create an event handler, simple place the code you want executed within the appropriate event listener:
<menuitem value="Click Me" onclick="alert('Event Handled.')" />
It follows from the description above that event handlers can be written for events that are fired somewhere below them in the hierarchy. A menubar in XUL, for instance, can contain event handlers for events fired by its child menuitems.
Mozilla XPArchitecture
Mozilla is obviously a lot more than simply an interface. It's cross-platform, and standards-based, and yet in some way, the event handlers written once in JavaScript and living in the XUL interface are getting very serious things done down in the application core. Things like socket interfaces, editing, mail, and security. The technologies that make this possible are perhaps the least understood of the phalanx of innovations that is Mozilla. In addition to the small matter of programming these serious things in C++ and compiling them platform for platform, the architects and developers of Mozilla use three "XP" technologies to link the core with the interface.
|
Figure 1. XUL, XPConnect, and XPIDL/XPCOM act as cross-platform glue technologies. |
Discuss this article in the O'Reilly Network General Forum.
Return to the O'Reilly Network Hub.
