W3C home > Mailing lists > Public > www-forms@w3.org > May 2006

An Ajax library, using XForms concepts [was RE: Deploying (accessible) XForms today?]

From: Mark Birbeck <mark.birbeck@x-port.net>
Date: Mon, 8 May 2006 13:33:46 +0100
To: <www-forms@w3.org>
Message-ID: <035901c6729b$a73f03e0$7e01a8c0@Jan>


> > Perhaps one angle to explore here is to work toward AJAX toolkits 
> > having more direct support for XForms.  Many of them are now 
> > introducing data models, model-view binding notations, and event 
> > systems.  If these were aligned more closely with XForms 
> we'd have a 
> > much better story not only for accessibiliy but in general...
> > 
> > Charlie Wiecha
> Excellent point, btw it would be a great start if AJAX-based 
> XForms implementations offered interfaces and APIs that are 
> sexier to the more general AJAX crowd and/or that make it 
> easy to integrate with frenzier libraries... 

Excellent point, too, Stefano! ;)

There are two parts to this; the first is to make some of the features that
are being popularised in Ajax libraries available to XForms authors, and the
second is to make the XForms architecture and standards available to those
still unlucky enough to have to use script.


Perhaps the most important feature that the current slew of Ajax libraries
have that XForms doesn't is an ability to animate the display. Sure, some
programmers like to dismiss this as 'eye candy', but we believe it is very
important for two reasons:

 * asynchronous form updates do actually require additional
   ways of conveying change to a user. Yellow highlights
   are the classic Ajax way, but they are GUI-bound; an
   XForms solution being accessible would allow also for
   whispers, and so on;

 * for XForms to succeed it needs to show that it can do
   everything that authors want to do, but more easily.
   There is no point in ignoring the desire to produce
   great looking user interfaces.

Having said all of this, I don't think that the animation effects themselves
should be in XForms, but rather in some new CSS module. But what we should
be thinking about is how to link up these effects libraries to the XForms

We've done quite a lot of work in this area over the last 6 months, and
although it's still work in progress, we've found that if you can do
this--link the effects features to XForms' higher-level concepts--you get
incredibly powerful UI at little cost. Some things that would be very
difficult to maintain in 'ordinary' Ajax become ridiculously easy when using
XForms with effects.

To achieve this we embedded a couple of Ajax effects libraries into
formsPlayer, and provided hooks so that you can make use of them from CSS,
rather than having to do the usual Ajax library stuff of creating extra
divs, calling functions to manipulate specific divs, registering handlers,
and so on. For example, in formsPlayer you can do things like this:

    -event-xforms-enabled   : fx-Effect-Highlight(duration:4.0

    -event-xforms-deselect  : fx-Effect-SlideUp(duration:0);
    -event-xforms-select    : fx-Effect-SlideDown(duration:1);

The first rule says that when any form control becomes enabled it should
have a 4 second highlight on the background. The second rule says that
whenever a <case> becomes selected it should slide down, and when it becomes
deselected it should slide up. In just a couple of lines of CSS you have
livened up your UI, but most importantly, you are dealing with high-level
XForms concepts and states (selected and deselected, enabled and disabled,
valid and invalid, and so on) rather than having to mess around with divs
and calling functions to affect those divs.

You can see this in use in the "Introduction to XForms" tutorial on our
skimstone site; there's a specific HOWTO on producing a Flickr search form,
and these techniques are shown in a section called "Animating the Display":


Note by the way, that this demo is based on one originally put together by
the Flex people. Interestingly enough, as with the Ajax approach, solutions
like Flex tend to bind behaviour like animations to actions such as 'user
clicks the mouse'. The XForms solution is far more sophisticated since the
animation is tied to the <case> changing state from deselected to selected,
which means that the animation will be triggered regardless of how the state
gets changed (which could be anything from a mouseclick on a <trigger> to an
action handler invoked as a result of a failed submission).


Using XForms to guide the production of an Ajax library is also a very
interesting area. We've pursued this by creating a so-called Ajax library
that in one sense is no different to any other Ajax library...except that
all of its features are based around XForms patterns and philosophies.

So, for example, nearly all of the Ajax libraries have a way of manipulating
a DOM, in one manner or another, but because our library is based on the
XForms architecture, we use the behaviour described in <setvalue>. The idea
is that since all of the behaviour of the setvalue method is defined clearly
in the XForms specification--deferred updates, recalculate, refresh,
datatype conversion, incorrect XPath expression, and so on--then we can
leverage that documentation and get a nice and clear specification for our
setvalue method. And if you do that for the whole Ajax library, you end up
with some very clearly defined behaviour and interfaces.

As you rightly point out, Stefano, this is very important, since current
Ajax libraries are all very different in how they handle data requests, UI
updates, validation, XPath, events, and so on. Our view is that even if two
different XForms-based libraries were created, they would still have pretty
much the same architecture, and the programmer could rely on having the same
events and methods available to them.

To illustrate the kind of thing we're doing, here is the setvalue function.
As you can see it very closely reflects the way the XForms specification
defines setvalue:

  this.setvalue = function(val)
      if (m_oDataSourceNode)
        if (typeof(val) == "string")
          m_oDataSourceNode.nodeValue = val;
          m_oDataSourceNode.nodeValue = val.stringValue();


      ...error handling...

Note that the reason we are doing this is because we believe that Ajax
libraries are useful for some things, but if you are going to use them, why
not use one based on standards, rather than one based on various proprietary
techniques? We can therefore provide a standards-based library for those who
need to use script, but we certainly wouldn't see that as a replacement for
coding in 'pure' XForms; XForms mark-up remains far, far better than
anything 'Ajax' has produced, or ever will.

We will be doing a 'lightening demo' of the formsPlayer Ajax Library on the
Ajax day at XTech 2006, later this month:




Mark Birbeck
x-port.net Ltd.

e: Mark.Birbeck@x-port.net
t: +44 (0) 20 7689 9232
b: http://internet-apps.blogspot.com/
w: http://www.formsPlayer.com/

Download our XForms processor from
Received on Monday, 8 May 2006 12:35:12 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 10 March 2012 06:22:04 GMT