Ubiquity XForms 0.7.0 Released

Ubiquity XForms version 0.7.0 has been released.

The Ubiquity XForms processor allows developers to use XForms markup to create interactive web applications. Ubiquity XForms adds new APIs leveraging a number of popular AJAX libraries, making XForms processing available in standard web browsers, without the need for a download.

Since the last release (0.6.2), the team has worked to resolve some 220 issues and worked towards better XForms 1.1 conformance. Here are the implementation reports for Firefox 3 and Internet Explorer 7.

Here is a slightly abridged version of the 0.7.0 release notes:

       Ubiquity XForms 0.7.0 Release Notes

               Notable Changes

 * Roll-up: Ubiquity XForms roll-ups can now be built, packaging the entire library in one JavaScript file.
 * XForms 1.1 submission: Support for many more xf:submission features, including the xf:header element.
 * Validation: Ubiquity XForms now supports validation against the XForms predefined datatypes.
 * Function extension: JavaScript function extension mechanism to define JavaScript functions that can be called in form XPaths.
 * New map controls: Adding maps to your forms as easy as placing a CSS class value on an xf:output or xf:range.

               New features

 * Conditional action handlers are now available via @if; 
 * Messages can be displayed using xf:message; 
 * More XPath functions have been implemented, such as context(), event() and id(); 
 * The xf:repeat start index (@start) is now taken into account; 
 * The xf:toggle and xf:setindex action handlers have been added; 
 * The xf:method child of xf:submission is now supported; 
 * There is SOAP support on POST submissions; 
 * Support for some of the semantics of XForms in HTML has been added; 
 * @incremental is now working for xf:input, xf:secret, xf:textarea and xf:range; 
 * SHA-256 support has been added to the hmac() and digest() XPath functions; 
 * File writing is available, by using the file: scheme and the PUT method in submission; 
 * File reading is also available, by using the file: scheme and the GET method in submission; 
 * More control over how a user navigates a form is available via@navindex and @accesskey; 
 * xf:input's that bind to boolean data will now render as a check-box.

               Test system improvements

 * Hands-free execution of unit tests; 
 * W3C Test Suite now uses the Selenium Test Harness; 
 * There are more Selenium user extensions for XForms-specific testing; 
 * A Buildbot server has been setup for automated testing and results generation.

               Other changes

 * Improvements to form controls, such as xf:range, xf:select and xf:select1 controls; 
 * Improvements to xf:repeat; 
 * Improvements to action handlers, such as xf:insert, xf:delete and xf:load; 
 * Improvements to resource handling in submission, via xf:resource; 
 * Improvements to messaging, via xf:hint and xf:alert; 
 * Improvements to the processing model and the events generated; 
 * Improvements in MIP handling; 
 * Lazy-authoring improvements; 
 * Fixed dynamic relevance on xf:group; 
 * Various style improvements for form controls; 
 * SVN has been better organized, which means that the directory structure differs from release v0.6.2.

For more details, see the UsingTheLibrary and Release0.7 project wiki pages.

A number of samples are available, including ones that show integration with YUI widgets such as calendars and color pickers, the Google Maps API etc. Here is a screenshot of the map controls:



More detailed posts on individual features in this release coming soon.

Dotting the i in review

Any project with a code repository needs to be diligent with its revision history. Design decisions are made (and sometimes reversed), people move on, and the origin and rationale for artifacts in code needs preservation for posterity. Some tools and code review styles lend better than others for subsequent code forensics and traceability. While the RTC development style (Review-Then-Commit) offers reasonable benefits at ensuring immediate quality over CTR (Commit-Then-Review), it may cause loss of valuable information if iterations to a proposed change happen in a medium that doesn't preserve history.

Lets compare a few techniques.

CTR. Apache Commons.

In Apache Commons, committers change code at will. Luckily, we have a bunch of subscribers that look over the SVN diff emails that get sent out and some errors get caught due to community oversight and fixed in ensuing discussion. For bugs and fixes, the ASF JIRA is set up to annotate issues with relevant SVN commit messages containing the issue identifier.



Not all commits are related to JIRA issues, and we haven't gotten into the habit of insisting the same, so often there are what I call standalone commits -- islands of activity that cannot be tied into the issue tracker, discussions or other project tools.

RTC. Apache Tomcat.

In Apache Tomcat, some parts of the repository need enough developer confidence before a change can be committed to trunk. A low overhead version of RTC is used. A text file (see the Tomcat 5.5.x STATUS.txt file) is used for bookkeeping. A code change is proposed with a pointer to the diff and opinions are collected via votes to proposed changes. When a change goes into trunk, the proposal in the STATUS.txt file is removed.

In some cases, patches are in the ASF Bugzilla so there is a better record of them. In other cases, patches are posted in committer's personal web spaces. If there is ensuing discussion and a patch is updated, multiple times even, that bit of the code evolution is not recorded for the most part at worst and harder to retrieve at best.

RTC++. Ubiquity XForms.

In the Ubiquity XForms project, we use what I refer to as RTC++. The two pluses stand for:

+ Effective use of tracker - Each change must be attached to an issue in the tracker. Each issue in the tracker must bear the correct status at all times (Accepted, Started, InReview, Resolved etc.) and pointers to all related commits must appear in the issue comments.

+ Commit stream as a doubly linked list - Every proposed change from a working copy must first be committed to SVN in the changes/ space. During the code review stage, any iteration in the changes/ space based on feedback during the review process must serve as a node in a doubly linked list like so: the commit message should point to the previous iteration which is being improved on (if any) and the code review space should contain a comment about the next iteration (or commit to trunk). All commit messages must contain the issue identifier.

While it may seem like a bit more process, its actually a trivial overhead to RTC when you get it, and having just spent a couple of hours on code forensics I'm personally glad for every occassion where it was used correctly.

For an actual example in action, see Mark's blog post using issue 515 I recently proposed as an example.