ake a look at the applications you deal with on a regular basis. Regardless of the platform or GUI that you use, or the programming language used to create them, there’s a certain innate commonality to applications: areas where you enter text, buttons (always buttons), menus, scroll bars, sliders, grids, trees, panes (or pages), and so forth. Certainly there are exceptions; graphics programs such as Photoshop or 3D Studio have much more sophisticated interfaces, and games are fundamentally all about interface. But for most business programs, such as accounting packages, word processors, statistical analysis applications, or a wide range of other programs, you’ll find a common set of abstract “components” that provide the bulk of interface functionality. In many cases these components also perform a significant amount of the intermediate processing?communicating directly with databases, setting internal variables to the application, persisting content, and so on.
If you think a bit more about such applications you also begin to see other pieces of commonality. Starting roughly fifty years ago, programmers realized that by creating an application that looped continuously, the application could retain its own internal state, working in “user” time to accept input interactively and generate output without terminating. This idea caused the shift from batch mode to interactive mode programming that underlies every windowed operating system today. Admittedly, most modern applications subscribe to a thread manager rather than creating a (system-locking) infinite loop; however, if you delve deeply enough into that thread manager, the loop is there, figuring out which thread to run at each successive pass.
The modern version of this application loop is called an event loop, named for its role in managing not just threads, but also the events that are passed from the system to various objects within the interface. Events that are not intercepted by some object within the event loop are recycled back to the system, which can discard them or handle them generically.
Event loops make it possible to load and maintain an internal state within the application. That state may be simply the contents of the visible form elements in the application, but more typically, the state is a separate model of which the visible interface is simply a reflection. When you load a file into the application, you are generally loading the model. Similarly, saving the file persists the model in a format understandable to the application.
HTML, as it exists right now, is at its core a batch document?the HTML content that describes a form is read by a browser and rendered as a Web page. In the absence of a scripting language, the form elements themselves are almost completely static?they cannot validate content, they do not interact, and most importantly, changing their states only sets the values of each control?there’s no underlying background model. You can add interactivity via scripting and working with the HTML DOM, but that’s not always portable between browser implementations, and still involves sending the interface representation to an external client, losing state the moment the client replaces the page with a new one.
If you take a look at a typical XForms viewer, you’ll find that it gives you much the same kind of structure as any other application framework does: moving from a batch to an interactive programming mode. Implementations differ, but all XForms viewers preserve and update internal state for the application.
The idea here is pretty simple?the View, or user interface, provides a set of controls that give the “public” face of the application. The only way you can interact with that XForm is through its public face. Every time you load the form, enter a word into a text box, move a slider’s thumb, or select an item from a drop down list, you change the state of a control, which in turn launches an event notifying the system that a change has taken place. You can then define actions (akin to event handlers) that occur whenever the event is fired for that particular component to update the internal model. You can also bind events to the model so that when a given value in the model changes, it forces an event to be launched that can be caught elsewhere.
If this sounds a lot like traditional event-based programming, that’s because it is. The only difference is that the event handlers, the event notifiers, and everything else are built with XML; you handle processing with XPath expressions, describe the model using XML schema, and fire events using the XML Events architecture.
XForms Is About Applications, Not Just Forms
It’s worth emphasizing the idea that XForms technology is about applications, not just about forms. One of the most common misconceptions that people have about the W3C XForms recommendation is that its primary purpose is to generate forms, such as job applications, building permits, and so forth, with the tight layout ability implicit in such forms. That’s an admirable goal, and it’s one that XForms could potentially fulfill, but this focus on “forms” also causes people to miss the real point of the language (and illustrates the danger of choosing names poorly).
XForms is not necessarily a Web language, though there are a number of Web based XForms engines. Instead, it’s a way to create an application that, with no scripting, can do such things as automatically reject invalid data, automatically update the contents of one control based upon changes in another, load content from external resources and send content to external URLs without leaving the application, retain state from one “page” to another, pass information into secondary dialogs, and so forth.
|
In other words, an XForms form is (superficially at least) similar to a Visual Basic Windows application or a Swing Java client program. However, because XForms is in essence an abstract representation of the application, it’s not language-specific. It’s entirely possible that you could use the same XForms document as the basis for a windowed application in either VB or Java, though doing that is beyond the scope of this article.
|
This abstract XForms representation takes place at a number of levels. The first, and most obvious, is the use of abstract controls to describe interface elements. Listing 1 contains a simple stock calculator. When you select a specific stock and enter a number of shares, the calculator determines the total stock price.
When rendered in a browser, the results look like Figure 1. I used the x-port formsPlayer plugin for Internet Explorer, so your application may look somewhat different.
 | Building a Model The second level of abstraction tied into XForms is the creation of models. A model represents an internal entity into which the interface (through the components) provides a window. Programming languages such as C# or Java usually reflect the model using classes and the relationships between classes. However, one of the benefits of working with XML is that it is generally much easier to create an internal model as an XML document than as a set of related classes. The user interface may not necessarily duplicate the model exactly. For example, in the stock example shown earlier, while the internal model represented the price of each stock and the final price as an integer, the interface showed the price as a dollar amount?45225.253 became $45,225.25. The user interface may hide some items or display computed quantities based upon the contents the internal model. The |