In the previous chapter, we saw how implementing a XOE service provides the behind-the-scenes logic for high-level user functionality; but what about the user interface? A platform-dependent windowing toolkit would work fine, but then we would have to rewrite our presentation layer for each platform. What we really need is a simple, portable method for displaying information to the user. Once we've discovered the user's wishes, what do we do with that information? How do we store user and application data? A database with a binary data format doesn't provide the portability required to deploy XOE on the scale we require - we need a platform-independent, scalable data storage solution.
These missing pieces to the application puzzle are found in a single answer: documents. Throughout XOE, the Graphical User Interface is provided by XHTML documents. System, configuration and user data are all represented as XML documents, as are many internal data structures.
There are a several reasons which make this a logical choice:
open standards supporting document usage
the highly portable nature of XML
user familiarity with documents as a medium for information exchange
The Document Object Model (DOM) is used to represent documents in memory.
XML Namespaces are used to manage and modularize documents.
The XML Path Language (XPath) is used to navigate and evaluate documents.
The Java class org.xoe.core.dom.XDocument extends org.xoe.core.dom.Document and is used by XOE to represent all XML documents. The XOE core libraries contain a service definition and a few implementations for building an XDocument.
public interface IDocumentBuilder extends IService { ... public XDocument getDocument (ContentElement content) throws IOException; }
The most commonly used implementation of this interface is the service org.xoe.core.content.text.xml, which returns an XDocument for content of the MIME type text/xml.
The XOE user interface is implemented using XHTML documents to describe the screens of an application. These documents are built using services that implement the org.xoe.display.dom.IViewableDocumentBuilder service definition:
public interface IViewableDocumentBuilder extends IService { ... public XDocument getViewableDocument (ContentElement content) throws IOException; }
Most applications get control of the screen via this interface. For instance, when an application is launched, the Application Manager service uses this interface to get the first screen to display to the user.
Complex documents can be built by embedding documents within larger documents. This is done by using the frameset or iframe tags, which have been previously well supported extensions to HTML and will officially become part of the specification with HTML 4.0.
In the above example, we saw how an application obtains control of the screen by implemented the IViewableDocumentBuilder interface. Once the Application Manager has found the application to launch, called getViewableDocument to get the application's first page and put the page on the screen, how do the user's actions get asynchronously relayed back to the application for processing?
In XOE, user actions are communicated through the framework via Callbacks. A callback is an inner class, defined within a service, which implements the interface org.xoe.core.dom.Callback.
Services register callbacks on a document so as to be notified when specific user events occur. For example, if a service is putting a document on the screen which has a button with an onclick attribute, it probably wants to be notified when the button is clicked. So the service registers an onclick callback with the document. When the button is clicked, the document finds the appropriate callback, in this case the onclick callback. The callback is then invoked at which point the service performs the appropriate task.