Slashdot Mirror

Adobe should move away from JavaScript and move to declarative form definition and validation, which carries no risk of code attacks from errant JavaScript. In fact, there is a standard for validating forms declaratively, called XForms. It lets you write validation expressions for saying when data is valid, required, readonly, or calculated from other data (i.e. totals), and also lets you assign data types using the widely-deployed XSD type names (integer, URL, string, regexp string, etc).

XForms is modular enough that it's been incorporated into ODF, and there's no reason other that it can't be used in PDF to define and validate forms, other than that Adobe has a vested interest in maintaining its proprietary technology forms instead. There are a number of folks who would be quite ready to help Adobe incorporate XForms into PDF.

There are in-browser JavaScript implementations of XForms (here, here, and here), server side implementations a la GWT (here and here), and mobile implementations (here).

I've been working with XForms for many years, and find it an excellent solution for deploying rich internet applications; we've switched implementations a few times, and have had to do only minor changes to our applications, so using a standard preserves our investment in stuff already written.

Try AJAX with markup only, no hand-written JavaScript, by using the W3C's XForms standard. There are a number of implementations such as the Servlet-based Chiba (which fronts for Dojo and other packages), FormFaces written entirely in JavaScript (no server-side component), entire server-side pipeline systems such as Orbeon, and full client implementations such as the Mozilla/Firefox XForms Extension (just type "xforms" into your Firefox extensions finder), FormsPlayer IE Plugin, or cell-phone capable implementations such as PicoForms and SolidForms.

I wrote an entire webmail reader using PHP for the back end and XForms for the client. It runs in the Mozilla XForms implementation but could easily be made to work in any of the above, which differ mostly in how the CSS works. xmlmail

And for completness, I was an editor of an earlier version of the W3C XForms recommendation.

There are also toolkits and JavaScript apps that combine W3C standards with AJAX, letting you write a lot of the dynamic page stuff in a declarative fashion, using just markup (XHTML+XForms; I was an editor of the XForms 1.0 recommendation, but new revisions have come out; see http://www.w3.org/TR/xforms).

The FormFaces OSS product is an entire XForms implementation done in JavaScript, running in the browser. You write your page in HTML with XForms markup, and FormFaces does the "HiJax" thing of re-writing it for you. You never need to use XmlHttpRequest, and you can interact with regular servers, RESTful services, etc., all via XML.

Another product that does this, in a slightly different way, is AjaxForms. I just found out about it, but it looks pretty good. AjaxForms uses some server-side components to do the translation from strict XHTML+XForms markup into Ajax (HTML4+JavaScript), but they claim it can work in PHP and Tomcat servers. Again, FOSS, and available at http://ajaxforms.sourceforge.net/ [sourceforge.net]

I recently implemented dynamic forms for weblogs and wikis, and did it using Chiba, another FOSS product, that like AjaxForms does its conversion on the server, using Tomcat as a container.

The Orbeon folks have a nice blog that shows how to use XForms (their implementation, the Mozilla extension, or any of the other above toolkits) to accomplish typical dynamic page tasks such as listing countries and ISO codes, or resizing flickr (also via formsplayer.

One good mechanism for getting the XML and asynchronous features but without hand coding JavaScript is to use any of the various XForms implementations. XForms is a W3C standard that defines a mostly script-free way of doing much of stuff people want out of Ajax, and it's done in a declarative way that's friendly to accessibility agents, and easier to deploy onto other devices. I was an editor of the XForms 1.0 recommendation, but new revisions have come out; see http://www.w3.org/TR/xforms

The FormFaces OSS product is an entire XForms implementation done in JavaScript, running in the browser. You write your page in HTML with XForms markup, and FormFaces does the "HiJax" thing of re-writing it for you. You never need to use XmlHttpRequest, and you can interact with regular servers, RESTful services, etc., all via XML.

Another product that does this, in a slightly different way, is AjaxForms. I just found out about it, but it looks pretty good. AjaxForms uses some server-side components to do the translation from strict XHTML+XForms markup into Ajax (HTML4+JavaScript), but they claim it can work in PHP and Tomcat servers. Again, FOSS, and available at http://ajaxforms.sourceforge.net/

I recently implemented dynamic forms for weblogs and wikis, and did it using Chiba, another FOSS product, that like AjaxForms does its conversion on the server, using Tomcat as a container.

Another important option is the work that the Mozilla Foundation and IBM are doing to make a native implementation of XForms as an XPI for Firefox and Mozilla. See http://www.mozilla.org/projects/xforms/ -- they're now in version 0.6, with 1.0 targeting full XForms 1.0 compliance. Like all other Mozilla extensions, it's a 1-click install, and I think it's about 200KB, so it's not very big, and I hope it gets added to the default build after it reaches 1.0. (It's presently built with the nightlies.)

There are a number of other implementations, including browser plugins (FormsPlayer for IE), native implementations for embedded devices such as cellphones and kiosks (PicoForms, SolidForms, and entire server-side systems using XForms, such as Orbeon Ops, so I see an increasingly bright future for using XForms to build dynamic HTML interfaces on top of XML web services and deploy them across a range of devices.

At my work, we've chosen the XForms route using Chiba for a recent product. It's not that surprising that I use it, because I was one of the editors of the 1.0 spec a long time ago, but it progressed even in my absence ;-) and it does fit many of the needs people describe here, in particular security and accessibility.

We write our dynamic markup in XHTML+XForms, following W3C standards (including nascent accessibility standards), and then use Chiba server-side in Tomcat to translate it into HTML4 and JavaScript. Chiba also offers a translation to HTML4 with a "refresh" button to initiate the dynamic activity via plain old HTTP, so it's fully accessible, though not as dynamic.

Longer term, please check out the Mozilla XForms XPI, which will take the XHTML+XForms markup directly. The browser does all its security stuff already, and it follows the IETF HTTP RFC and other W3C specs directly, so there's no need for funky workarounds or security lifting. The Firefox implementation is at rev 0.5 or 0.6 about now, and it's definitely usable, but when it gets to 1.0 it will be really great for dynamic behavior.

There are other implementations as well, FormFaces, which is written entirely in JavaScript and is way cool, FormsPlayer for IE, with lots of advanced features and which is a plugin, not a native implementation (as in the Firefox one); X-Smiles, the open source standalone implementation from Finland, SolidApp, another OSS one with paid support for small devices (mobile phone vendors look here), PicoForms, also for embedded apps but not OSS, Orbeon, a complete back-end server solution incorporating XForms and pipelines. I'm sure there's more major implementations I've missed, and also partial ones as well.

If you want to know more check out the XForms FAQ and XForms or HTML authors Part 1 and Part 2.

Plus, Will Wheaton likes it.

A lot of the middleware that converts data to HTML and back can go away when you use the right XML tools. XSLT does a good job of presenting static pages, and it can be fast if you cache the results as well.

But for dynamic pages (and forms) XML to XSLT to HTML leaves some big gaps:

1. The hierarchical XML data gets flattened out into name/value pairs in HTML form fields.
2. For the return trip HTML->?->XML, XSLT doesn't work; you can't run the transform backwards.
3. For dynamic pages, you're left with JavaScript or the dreaded "postback."

These are some of the reasons we updated the W3C HTML forms module to take account of XML data directly.

How does it fix the above problems?

1. The hierarchical XML data your PHP or other server-side code outputs is transmitted directly to the web browser, where it remains while the user futzes with only the nodes that the form specifies. The middleware that converts the XML data to web browser data is just printing the XML.
2. When the form results are submitted, they come back directly in XML, so there's no need to pick apart the name=value pairs and try to put them back into your data. The browser just posts the XML directly back as XML to your PHP or servlet.
3. For forms, as the data changes, the UI changes with it. If a node disappears, or appears, or if a value changes, entire sections of UI can appear and disapear just by listing a dependency on that data. And if you want dynamic pages, you can use the background submission feature to retrieve instance data asynchronously, and the presentation changes automatically.

Nice work if you can get it, you say? Well, as everyone knows Microsoft hasn't yet implemented XForms. (Heck, they haven't even implemented CSS, though we hear they do have it as a goal now.)

So what can you do today:

1. Use Mozilla or FireFox XForms 0.4. It's a one-click install download from the Mozilla website. Yes, it's beta. Yes it has bugs. Yes, IBM and others are fixing them. But it's open source.
2. Use FormFaces for most modern browsers (Firefox, IE, Safari, Opera) FormFaces is a cool JavaScript/AJAX application that you import into your web page with a one-line include, and it does everything described above. If you need cross-browser support right now, want dynamic AJAX forms, and want to interface to XML, this is your best bet, if you can tolerate a JavaScript program in your browser (i.e., it's done using AJAX). It's available under GPL and commercial licenses.
3. Use Chiba for backend processing Chiba is an open source Java-based back-end that converts your XHTML+XForms page into either an AJAX page or a static HTML page (good for Sec 503 compliance). Chiba is a great choice for applications that have a Java back end, as it puts less load on the browser than the large JavaScript engine of FormFaces, but I put it below FormFaces here because of the emphasis on PHP. (But, about half of Chiba is an XSLT transformation so a PHP port is possible.)
4. Use Formsplayer as an IE plugin FormsPlayer is a deluxe XForms processor plug-in for intranet applications using Internet Explorer, and has lots of other features as well, such as sidebar support.

Here's a quick example:

Let's suppose you have a book list you want to view, avaialble at http://example.com/books/list.

<books>
<book>
<title>No Nonsense XML Web Development with PHP</title>
<author>Thomas Myer</author>
<book>
...
<books>

If you want to display this data

• FormFaces A pure AJAX library that runs in today's browsers. It's stunning to see how simply this works.
• Chiba A server-side engine in Java that integrates with TomCat or other Apache web server technologies to produce HTML that works in today's browsers. Plus, the plain-old-HTML output of Chiba is accessible right now, in addition to the XHTML+XForms file itself. (Caveat: Full AJAX implementation is in development, according to the mailing list.)
• Orbeon Ops, like Chiba, Orbeon converts to HTML for today's browsers in its Java back end, but rather than integrating into your TomCat or Coccoon framework, it comes with its own framework that helps you separate presentation from content and write your applications.

• Mozilla XForms for Mozilla and FireFox, an XPI that's available for recent betas and nightlies, this one-click install adds native XForms support to these browsers. Still in Beta, but with plenty of developers, it should be a full implementation.
• FormsPlayer for Windows provides full support for XForms in Internet Explorer via a plug-in. Plug-ins are not everyone's cup of tea, but then neither is Mozilla ;-). You can get the AJAX benefits of dynamic page updating and yet still retain accessibility with any of the server-side or JavaScript engines above, but if your target deployment is Internet Explorer, you can gain tremendous access to advanced features inside IE with this plug-in. (Plus it has some neat Konfabulator-like tools such as SideWinder.)
  

XForms is a standard from W3C, and is accepted by the accessibility people.
There are some "AJAX" (no offence intended to Mr. Hixie) implementations of XForms, one being Form Faces, a GPL/Commercial dual-licensed library. Rather than investing a lot of effort to learn the ins and outs of Javascript and browser packages for these features, why not try a standard way of doing most of this stuff. Granted, it won't give you the seamless scrolling of terabyte bitmaps like Google Maps does, contributing effort to an AJAX implementation of XForms (and eventually the current Beta Mozilla implementation) will lead us closer to accessibility and declarative web programming, and will give the HTTP+XML benefits people are seeing from these hand-crafted AJAX applications.