BigBison
March 22nd, 2006, 11:51
I've been working a lot lately with mixed XML/Javascript frameworks, and curiously enough, the more complex the applications become, the more that they in fact begin to resemble ... well, XForms. You have one or more XML data stores that can represent anything from a personal schema to a description for an entire set. You have a series of bindings that determine the boundaries and secondary processing of data between components, you have event notifiers that get passed from object to object in a subscription oriented framework. All of these facets, and more, are critical pieces of the XForms space.
In point of fact, you can create some incredibly rich "web experience" applications that are mixed XHTML and XForms, and can do so in a remarkably short amount of time. These are not simply empty text fields that you lay out as you do with HTML >input< elements - XForms bears about as much resemblance to HTML forms as a Bengal tiger has to a ferret. If you go back far enough you'll probably find that they share a common ancestor (they do, in fact - a weasel-like tree dweller called a Miacis, from about 50 million years ago), but in many ways XForms is more the harbinger of a new web development architecture where the application (the web page) holds a model that either populates or is populated by various XML form elements. When the model changes, so do the form element contents. When the form elements change, so does the model. This is handled automagically in the background, using the power of XPath expressions and data bindings to create sophisticated applications.
So how does this differ from the "traditional" AJAX application? The difference comes from the nature of that automagic, which is far from being either automatic or magical in the latter context. In an AJAX application, you explicitly sit on the page load tag to grab an XML (or related) resource from the server, creating an asynchronous call that will update an explicitly defined model, then write more code that will walk through that XML model and either pass it to an XSLT transformation or run it through more DOM manipulation code in order to explicily populate the fields in question in the web page (any more explicit and it would require an X rating). You can cut this code down considerably with some carefully coded libraries, but these libraries add to the overhead of both loading and maintaining the page, sometimes significantly, and if they are not well written can also add a considerable burden to the debugging department.
On the other hand, an XForms like architecture defines XML data models, constraints, and bindings explicitly as rules given within an a declarative XML format. This declarative form works in a manner similar to that of an Excel spreadsheet. In Excel, for instance, you define both blocks that hold initial data then you have functional blocks that perform calculations either upon the initial data or a previously defined functional block. What you end up with in this kind of declarative "program" is an application where the "answer" may in fact be a lot of different pieces of information, where the only action involves the changing of one or more initial values, and where constraints will at a minimum prevent you from entering erroneous data.
Whether talking about spreadsheets or XForms, the one dominating factor in both cases in their development is the recognition that you are creating such a form in its entirety, at every single point within the application process itself. This is a fairly subtle concept, but its an important one. When you create an imperative script, at any given point in the process that script will be incomplete, perhaps to the point of being unrunnable. This means that most development requires that you create fairly complex modules, run (or compile) them, then spend time trying to figure out why you're not getting any answer coming from out of the black box. It necessitates at the beginning having a comprehensive idea about what pieces you will need to construct the application, and so places a premium on planning in environments where planning and design budgets are usually pushed to the absolutely minimum.
In a declarative model such as XForms, however, so long as your syntactical structures are intact (i.e., so long as you have clearly defined well-formedness) your model will run. You CAN, of course, design forms that do not check for valid data, so there is no guarantee with XForms (or Excel for that matter) that your model will return anything meaningful. In other words, garbage in - garbage out still applies. However, introducing constraints in such an application is also not hard to do, making it much more difficult to insert garbage in the first place.
http://www.oreillynet.com/xml/blog/2006/03/why_xforms_matter_revisited.html
The w3c standard:
http://www.w3.org/TR/xforms/
A nifty toy I may have to play with:
http://www.formfaces.com/main.html
In point of fact, you can create some incredibly rich "web experience" applications that are mixed XHTML and XForms, and can do so in a remarkably short amount of time. These are not simply empty text fields that you lay out as you do with HTML >input< elements - XForms bears about as much resemblance to HTML forms as a Bengal tiger has to a ferret. If you go back far enough you'll probably find that they share a common ancestor (they do, in fact - a weasel-like tree dweller called a Miacis, from about 50 million years ago), but in many ways XForms is more the harbinger of a new web development architecture where the application (the web page) holds a model that either populates or is populated by various XML form elements. When the model changes, so do the form element contents. When the form elements change, so does the model. This is handled automagically in the background, using the power of XPath expressions and data bindings to create sophisticated applications.
So how does this differ from the "traditional" AJAX application? The difference comes from the nature of that automagic, which is far from being either automatic or magical in the latter context. In an AJAX application, you explicitly sit on the page load tag to grab an XML (or related) resource from the server, creating an asynchronous call that will update an explicitly defined model, then write more code that will walk through that XML model and either pass it to an XSLT transformation or run it through more DOM manipulation code in order to explicily populate the fields in question in the web page (any more explicit and it would require an X rating). You can cut this code down considerably with some carefully coded libraries, but these libraries add to the overhead of both loading and maintaining the page, sometimes significantly, and if they are not well written can also add a considerable burden to the debugging department.
On the other hand, an XForms like architecture defines XML data models, constraints, and bindings explicitly as rules given within an a declarative XML format. This declarative form works in a manner similar to that of an Excel spreadsheet. In Excel, for instance, you define both blocks that hold initial data then you have functional blocks that perform calculations either upon the initial data or a previously defined functional block. What you end up with in this kind of declarative "program" is an application where the "answer" may in fact be a lot of different pieces of information, where the only action involves the changing of one or more initial values, and where constraints will at a minimum prevent you from entering erroneous data.
Whether talking about spreadsheets or XForms, the one dominating factor in both cases in their development is the recognition that you are creating such a form in its entirety, at every single point within the application process itself. This is a fairly subtle concept, but its an important one. When you create an imperative script, at any given point in the process that script will be incomplete, perhaps to the point of being unrunnable. This means that most development requires that you create fairly complex modules, run (or compile) them, then spend time trying to figure out why you're not getting any answer coming from out of the black box. It necessitates at the beginning having a comprehensive idea about what pieces you will need to construct the application, and so places a premium on planning in environments where planning and design budgets are usually pushed to the absolutely minimum.
In a declarative model such as XForms, however, so long as your syntactical structures are intact (i.e., so long as you have clearly defined well-formedness) your model will run. You CAN, of course, design forms that do not check for valid data, so there is no guarantee with XForms (or Excel for that matter) that your model will return anything meaningful. In other words, garbage in - garbage out still applies. However, introducing constraints in such an application is also not hard to do, making it much more difficult to insert garbage in the first place.
http://www.oreillynet.com/xml/blog/2006/03/why_xforms_matter_revisited.html
The w3c standard:
http://www.w3.org/TR/xforms/
A nifty toy I may have to play with:
http://www.formfaces.com/main.html