As I write this, two technologies are gaining incredible momentum and creating a small revolution in their respective application spaces as they have just been or are nearing release. XForms, the long-awaited successor to HTML forms, goes beyond a mere XML brush-up. XForms provides an XML editing solution with an abstracted user interface layer. Meanwhile, Scalable Vector Graphics (SVG), gears up for its second minor version upgrade that dramatically broadens its usage scenarios, making it more adaptable and extensible than ever. This series introduces the new angles taken by both technologies and shows how they can be integrated. This primer starts the exploration with an analysis of XForms and SVG, and how they might relate.
XForms succeed HTML forms but the importance of HTML forms in the development of forms-based interactions should not be overlooked.
A bit of history -- HTML forms
I will assume that as a reader of the developerWorks XML zone, you probably have some working knowledge of HTML (and subsequently XHTML) and its forms capabilities. HTML forms enabled the first interactions between a client and a server, going further than the request of static documents. HTML forms were a very down-to-earth approach to providing Web content developers with the means to let users interact with text data through different pre-set widgets: simple input fields, text areas, radio buttons, combo boxes, and selection lists. It is an understatement to say that HTML forms have played a big role in making the Web what it is today, but it's important to remain focused on what this actually means. The Web has not simply turned out to be an incredible communication medium that helped blossoming new trends, a whole new economy, and so forth. Indeed, Web development itself did not turn out to be as rosy as it sounds. Every developer who's been part of creating even a relatively simple Web application that relies on forms-based interaction can give you a list of annoyances that, without a doubt, includes the exact problems that XForms aims to solve -- validation and the limited value of the user interface controls being two of them.
In the HTML days, validation usually turned out to be a real headache, and to solve this developers generally took one of three approaches. The first and most straightforward approach consisted of letting the server handle validation, most likely through the help of a scripting language like Perl. Writing such programs was a tedious task and provided a poor solution as a new document had to be sent back (and later re-processed) every time an error was encountered in the form validation process. The second approach was to validate on the client, which involved JavaScript-based scripting wizardry on a completely platform-dependent object model. The third approach consisted of a combination of the first two methods. Whichever approach was used, the results were never satisfactory as the work required was still very daunting.
On the user interface front, things were not very exciting either. All the UI widgets that I list above were fine at the outset, but issues appeared soon enough. The range of UI widgets was fairly small, and to offer richer input mechanisms -- such as a calendar for choosing a departure date -- one had to resort to clever client scripting and the dreaded DHTML approach, with its heavy bag of incompatibilities. The appearance and behavior of each form widget was basically tied to the specific platform. Although this allowed for nice integration with the user environment, it limited possibilities for creating completely custom widgets, as well as a more simple modification of the graphics for branding purposes or consistent look and feel across platforms.
While validation and user interface controls alone were big enough problems to start work on a new solution for forms, device dependence, accessibility issues, and lack of integration with XML were also noteworthy issues. All of these concern points were taken into account when the W3C started to develop what was to become the next generation of Web forms.
Nowadays, many Web applications revolve around XML. A growing number of these applications bring the power of XML all the way to the client (using XHTML, for example). XForms are tightly linked to the XML platform and thus fit perfectly into this type of workflow. XForms introduce a radically new approach to forms by completely separating the model and the presentation of a form.
The model of a form is basically a structured placeholder for the data that the user fills using an appropriate user interface. In XForms, the content developer specifies the model using XML, which allows for a purpose-specific structure of the model by using the custom grammar that fits best. Once the model is defined, all that remains is to specify which parts to expose through a user interface.
The way you specify a user interface with XForms is rather abstract, and you never make a direct specification of what your UI needs to look like. Rather, the content developer uses built-in XForms elements for the user interface. In a high-level way, the XForms elements specify how the user may input or select a value for a given element in the model (referenced through an XPath expression). To make this last sentence a little less abstract, consider that in HTML you said "draw a text-entry widget so that the user can input a date string", in XForms you say "give the user the right widget to select one value that is fit for my model."
That's fine, but how exactly does this help solve those old issues? What really makes defining the XML model spiffy is that you can actually bind a datatype (using either built-in W3C XML Schema datatypes or XForms' own) to any element in the model. This has several advantages. First, when a value is typed in or selected through a widget, validation for this value can be done automatically by the XForms implementation given the datatype. Also, since your model element has a datatype, when you reference it through a user interface element, you can be sure that the user will be presented with an appropriate way to provide a value. So, for instance, recall that with XForms you could say "give the user the right widget to select one value that is fit for my model" -- if the value you want to provide is a date, then chances are the implementation will recognize the hint and display a calendar widget for you to provide the date.
Believe it or not, I have barely scratched the surface of XForms here -- for further material on this, see Resources. One drawback of HTML forms that I mentioned earlier was the lack of stylability. In XForms, none of the user interface elements have a set appearance, since those elements only define constraints on the interaction (like the number of items that can be selected). The datatype acts as a hint for the implementation to present the user with an appropriate input widget. You can use SVG to act as the presentation and interactivity layer of XForms. Take a look at how SVG has been progressing lately and how these developments fit this hypothesis.
The potential synergy between XForms and the new features of SVG creates many possibilities.
SVG 1.0 became a recommendation in September 2001, and since that time it has been put to use in a broad variety of industries. Noteworthy applications spaces have included mapping and graphing. Recently SVG has had more and more application-centric development on its own through open source projects aimed at providing libraries for re-usable, SVG-based user interface widgets. All these projects have used the association of a scripting language (usually ECMAScript) and the DOM (including the SVG-only extensions) as the foundation of interactive SVG.
While the foundation was the same for all, the architecture of the libraries took different paths. A very straightforward way to conceive such architectures was to offer an object-oriented ECMAScript API to your library. Thus, if I wanted to create an SVG combo box, I could provide an SVGComboBox class.
The user could instantiate the class, call a few methods to fill in parameter values, and command drawing -- very much like your usual UI toolkit in traditional frameworks (such as Swing, WinForms, and Aqua). While these libraries would indeed be built atop SVG -- offering APIs to abstract the DOM-scripting internals of their libraries -- integration with the SVG language itself was almost nonexistent. Additionally, using the custom API of each component included a learning curve, and had no built-in XML benefits, such as declarativity or semantics.
A cleverer way to provide a re-usable library was to have some XML acting as a public API. Going back to my combo box example, I could offer the user an XML element expressed in my own namespace, such as <ui:comboBox>. Some part of my library parses the whole document at load time to check for occurrences of my <ui:comboBox>, and then constructs an SVGComboBox object. Basically, the <ui:comboBox> element acts as shorthand for calling all the necessary methods on my SVGComboBox instance. Since my custom element is part of the DOM, I could also use mutation events when the user, through the DOM APIs, accesses my custom element and tweaks one of its attributes -- say its x position or its contents. As time passed, this approach was deemed more appropriate by many developers who believed the XML-centric approach was a better fit for an SVG environment.
However, this approach proved to be less optimal than originally thought. Rendering was still done in the document tree, and this proves disruptive in a number of cases. Dumping everything in the same tree has risks. The most important risk is that messing with the original structure may well result in incompatibilities between different extensions that make assumptions about what is in the document tree.
A number of SVG developers have been discussing approaches for building extensions atop SVG. This discussion has provided the W3C SVG Working Group with the information necessary to work toward solving the problems with the specification. The first signs of the solution are found in the SVG 1.2 and a new feature called RCC.
Pushing the envelope: RCC and SVG 1.2
Rendering Custom Content (RCC) is the new foundation framework for using custom XML grammars in an SVG context. The RCC framework provides a fairly light layer built on top of technologies and concepts that are available in an SVG implementation.
One of the main sources of happiness that RCC brings to developers is that it exposes an SVG 1.0 concept that was pretty well hidden previously: shadow trees. Shadow trees were used in SVG 1.0 for the expanded SVG representation of the <use>, <pattern>, and <marker> elements. Until now, manipulation of a shadow tree was contained within the implementation, and RCC exposed it by allowing any element in a foreign grammar to have a shadow tree,
and in a public way, too. SVG 1.2 exposes new DOM APIs for accessing a shadow tree; regular DOM APIs then allow you to manipulate it like the regular document tree. So now, for example, all your generated graphics and attached event listeners live in a contained tree that's impossible for another component to stumble upon unless it really intends to do so (fully knowing that doing anything there may be disruptive). With shadow trees, the only thing that remains in the document tree is your custom element and nothing else.
It's one thing to have your custom element scriptable using the DOM and integrated into the document tree in a civil manner; but if you really want your element to act like any other SVG element, it needs to be able to evolve on the events side of things as well. Another great thing related to RCC is the inclusion of two new standards in SVG 1.2: DOM Level 3 Events and XML Events (see Resources). With DOM Level 3 Events, you can create a purpose-specific event of a custom type. Thus, my <ui:comboBox> can dispatch a select event when the user selects a new value using my graphical representation of the element (which lives in its shadow tree).
Dispatching custom events is fine, but you also need to be able to listen to those events. To do so, you can use the old DOM Level 2 route, using the EventTarget::addEventListener() method. However, this implies a programming context, and it is often desirable to use a declarative approach to listening to events on a given element. Using XML Events, you can listen to any event, built-in or custom, using a standard declarative syntax -- without resorting to dodgy attribute-based event listeners (like onmouseover and friends). Still, on the event side, RCC brings in two new built-in events in SVG, relative to the binding mechanism of a foreign element with an RCC definition. As you will see in the next installment of this series, these two events, along with the whole RCC framework, are a beautiful thing and allow an SVG developer to provide custom elements that behave much like regular SVG citizens, paving the way for SVG to act as a new programming platform for any XML application.
XForms is a highly-abstracted, XML-based solution to the challenges presented by HTML forms, with a very clean separation of data and presentation. Meanwhile, SVG 1.2 offers a more extension-prone platform, with shadow trees and slick event integration, all encapsulated within the RCC framework. With that in mind, you should be all set to create custom UI elements in a clean way with RCC, and re-use these custom components in an XForms context to provide a rich user experience. The next article in this series will focus on creating an RCC-based SVG component, and later I'll delve into XForms integration.
- Go straight to the source -- read the XForms 1.0 and SVG 1.2 specifications on the W3C.
- Try creating a simple push-button widget with the RCC mechanism in "SVG and XForms: Rendering Custom Content" (developerWorks, November 2003).
- For background on SVG, check out the developerWorks tutorials
"Introduction to Scalable Vector Graphics" (February 2002)
and
"Interactive, dynamic Scalable Vector Graphics" (June 2003).
- Get more background on XForms with these developerWorks articles and tutorials.
- Learn how the next generation of Web forms can help you build online forms that are extensible and suitable for any platform with "Get ready for XForms" by Joel Rivera and Len Taing (developerWorks, September 2002).
- Read Micah Dubinko's introduction to the topic: "XForms Essentials."
- Find out more about XML Events at the W3C site.
- With DOM Level 3 Events, you can create a purpose-specific event of a custom type.
- Find more XML resources on the developerWorks XML zone.
- Learn how you can become an IBM Certified Developer in XML and related technologies.
Antoine Quint is an independent SVG consultant and research scientist participating in the W3C SVG Working Group as an invited expert. He also enjoys teaching, presenting at conferences held in nice places, and doing outsourcing work, all of this SVG-oriented. When at home in Paris, he lives with his über-cat Stig Elmer. Antoine also has a much-delayed book in the works with his old pal Robin Berjon.
Comments (Undergoing maintenance)
Local resources
My developerWorks community
Tags
Use the slider bar to see more or fewer tags.
Popular tags shows the top tags for this particular content zone (for example, Java technology, Linux, WebSphere).
My tags shows your tags for this particular content zone (for example, Java technology, Linux, WebSphere).
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
