It seems as if XML-based languages for descibing forms and UI elements are proliferating. XUL, XAML, and XForms are three of these. What do you think of the future of these technologies? Wave of the future, or temporary sideline? Given that so much ink has been written advocating the separation of form and function (model/view/controller), does moving the UI description to XML constitute a better and cleaner separation than past attempts at addressing the problem? Do you think XForms will become the standard, or are XUL and XAML too far ahead in implementation? Let us know in the xml.general or design.ui discussion groups.
XForms recently reached the W3C's Candidate Recommendation status—and you need to know about it—because XForms isn't a form description language, it's a language for describing applications in a platform-independent way. Best of all, it integrates easily with technologies you already know, such as XHTML, XPath, SVG, and CSS.
by Kurt Cagle
November 6, 2003
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.
It's quick, easy and you get access to all the articles on DevX.
This registration/login is to allow you to read articles on devx.com. Already a member?
To become a member of DevX.com create your Member Profile by completing the form below. Membership is free!
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.
