W3C home > Mailing lists > Public > www-forms@w3.org > March 2005

RE: XForms Myths Exposed - By Ian Hixie (Opera)

From: Mark Birbeck <mark.birbeck@x-port.net>
Date: Fri, 11 Mar 2005 18:16:51 -0000
Message-ID: <BA57A79E-C84F-4F17-8259-3D49040484B8@S009>
To: "'Ian Hickson'" <ian@hixie.ch>
Cc: <www-forms@w3.org>

Ian,

> The progression, IMHO, is really between the generally high 
> skill set of your average XForms author and the comparatively 
> low skill set of your average HTML author.

XForms caters to both -- it allows you to do very powerful things more
easily, as well as very simple things more easily (more on that, below). It
is much more powerful than HTML+JavaScript, yet does it with clean mark-up.
In some ways it is comparable to VB or even C++/C#/Java. But at the same
time, a simple form, with data submitted to a server, is no more difficult
than it is with HTML (and any form that is just a bit above 'simple' is
much, much easier than the equivalent HTML, since it doesn't require
scripting).



ADVANCED XFORMS

An example of the advanced features of XForms is -- and I know I've
mentioned it before -- our RSS Reader:

  <http://www.formsplayer.com/bars/rss-reader.html.txt>


> (Take the recent XForms calculator as an example. It uses 
> tables for layout, a highly inaccessible way of presenting an 
> interface.)

I understand that the calculator was written by someone who had only
recently learnt XForms, and I think they did pretty well! Anyway, our reader
does not use tables, it keeps the data and program logic separate from the
UI, and it even has device-independent 'tabs' (but unlike WebForms 2.0 which
has tabs in the language, these tabs are simply the rendered reflection of
clearly defined behaviour -- which is much, much better). And a key feature
of this form is that it is state driven, making it very easy to maintain and
add new features.

Yet this reader is as powerful as most that you'll see available for sale,
supporting all the RSS dialects. And it is easy to extend, since all of the
application is available as straightforward mark-up -- you could take the
reader and re-brand it for your own server, or even place it on your local
machine and start customising it, since it's just an XHTML file.

Anyone who would like to see how the RSS Reader behaves, but doesn't have
formsPlayer 1.3 installed, can view a Flash video here:

  <http://www.formsplayer.com/videos/640x480/config.html>



EASY XFORMS

I wouldn't claim that the RSS Reader application is something that your
average HTML author would be able to develop (or even want to!), although it
would certainly be pretty straightforward for a C++/C#/Java programmer, and
probably not that much of a stretch for a VB or experienced HTML+JavaScript
programmer.

But XForms also makes the easy things very easy. The following mark-up does
just what an ordinary HTML form currently does:

  <html xmlns="http://www.w3.org/2004/xhtml2/">
    <head>
      <title>Booking</title>
      <model>
        <submission id="sub"
         action="http://www.example.org/update.asp"
         method="get" />
      </model>
    </head>
    <body>
      <input ref="fn">
        <label>First name</label>
      </input>
      <submit submission="sub">
        <label>Save</label>
      </submit>
    </body>
  </html>

(Note that for a more direct comparison with HTML, I'm using the new XHTML 2
syntax, which doesn't require a separate namespace for XForms. To use any of
these examples in current implementations one would simply change the XHTML
2 namespace to XHTML 1.x, and add the XForms namespace.)

Activating this submission will cause the current document to be replaced
with the result of a GET request to the URL:

  http://www.example.org/update.asp?fn=Blah

The mark-up doesn't look that difficult to me!

I'll show some of the many things that we can do in XForms that you can't do
in HTML unless script is used:



SAME DATA ... DIFFERENT SERVERS

We can have more than one 'form':

  <html>
    <head>
      <model>
        <submission id="sub-update"
         action="http://www.example.org/update.asp"
         method="get" />

        <submission id="sub-delete"
         action="http://www.example.org/delete.asp"
         method="get" />
      </model>
    </head>
    <body>
      <input ref="fn">
        <label>First name:</label>
      </input>
      <submit submission="sub-update">
        <label>Update</label>
      </submit>
      <submit submission="sub-delete">
        <label>Delete</label>
      </submit>
    </body>
  </html>



POST GETS MORE POWER

We can still do an 'old-style' post:

  <html>
    <head>
      <model>
        <submission id="sub-update"
         action="http://www.example.org/update.asp"
         method="form-data-post" />
         .
         .
         .

But now we can also submit 'real' XML:

  <submission id="sub-update"
   action="http://www.example.org/update.asp"
   method="post" />

Yes, that's all that's needed ... Just set @method to "post" and you get an
XML submission. No XMLHTTP objects wrapped in JavaScript classes to try and
make them work on Mozilla, IE and the rest (see JS apps like GMail and
Google maps for examples of how to 'wrap' XMLHTTP).



VALIDATION

What if we want to check the data entered? All we need to do is bind a data
type to the data and the processor will do the rest:

  <html>
    <head>
      <model>
        <submission id="sub"
         action="http://www.example.org/update.asp"
         method="get" />

        <bind nodeset="date" type="xsd:date" />
        <bind nodeset="beds" type="xsd:integer" />
        <bind nodeset="smoking" type="xsd:boolean" />
      </model>
    </head>
    <body>
      <input ref="fn">
        <label>First name:</label>
      </input>
      <input ref="date">
        <label>Date:</label>
        <alert>Must be a date</alert>
      </input>
      <input ref="beds">
        <label>Beds:</label>
        <alert>Must be an integer</alert>
      </input>
      <input ref="smoking">
        <label>Smoking:</label>
        <alert>Must be true or false</alert>
      </input>
      <submit submission="sub">
        <label>Save</label>
      </submit>
    </body>
  </html>

The XForms processor will check the data entered against the data types, and
give feedback on any errors.

The processor will also prevent the data from being submitted if it's
invalid, so if we want an error message when the user tries the submission,
we do the following:

  <model>
    <submission id="sub"
     action="http://www.example.org/update.asp"
     method="get"
    >
      <message level="modal" ev:event="xforms-submit-error">
        Please correct your data, and try again.
      </message>
    </submission>

    <bind nodeset="date" type="xsd:date" />
    <bind nodeset="beds" type="xsd:integer" />
    <bind nodeset="smoking" type="xsd:boolean" />
  </model>

Still no script, and all of this is well within the capabilities of most
HTML authors, unlike the scripted alternative, which requires 'programming'
ability (and probably experience of regular expressions!).



IMPROVED USER EXPERIENCE

One effect of binding data types to the data in the previous example is that
the controls showing that data will appear differently -- if the data type
is xsd:date then a calendar widget should be rendered, if it's xsd:boolean
then a boolean widget should be rendered (on a GUI that would be a check
box). No more scripting calendar controls that probably only work in one
part of the world anyway!

But there's more -- what if we want to add some 'mouseover text' (that is
platform independent, so will work in voice browsers too)?:

  <input ref="beds">
    <label>Beds:</label>
    <hint>How many beds in the room?</hint>
    <alert>Must be an integer</alert>
  </input>
  <input ref="smoking">
    <label>Smoking:</label>
    <hint>Would you like a smoking room?</hint>
    <alert>Must be true or false</alert>
  </input>

And some help text, most likely invoked when the user presses F1, or the
equivalent:

  <input ref="beds">
    <label>Beds:</label>
    <hint>How many beds in the room?</hint>
    <help>
      Please indicate how many beds you would
      like in the room. If you would like babies
      cots, then please enter that in the 'Cots'
      field.
    </help>
    <alert>Must be an integer</alert>
  </input>

We've now got a lot of functionality -- validation, error messages, calendar
controls, hints and help text -- yet we still haven't had to write a single
piece of script. And our form will run on any XForms processor that conforms
to the standard. How many HTML+JavaScript programmers could make the same
claims for their web-sites?


> The reason, IMHO, that most XForms now is better in terms of 
> accessibility is simply that the authors writing it are 
> learning how to do it right. If XForms reaches a critical 
> mass where authors from the "copy paste" line of work become 
> prevalent, then accessibility will suffer as it did with HTML.

The previous mark-up shows pretty clearly that this is simply not the case
-- the accessibility benefits from XForms are built into the language, and
the whole reason for doing that was so that it would be easy for the authors
to add accessibility without even having to think about it.



CONCLUSION

Whilst you are right Ian, to say that the complicated applications that you
can produce with XForms will be out of the reach of the average HTML
programmer, I would say that you are wrong to imply that XForms raises the
bar for authors more generally. In fact, as my examples show, XForms allows
you to produce forms with a lot of functionality, but without using any
scripting, which means that XForms actually *lowers* the bar, allowing those
who do not know scripting to produce more useful, device-independent,
cross-platform forms.

Regards,

Mark

Mark Birbeck
CEO
x-port.net Ltd.

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

Download our XForms processor from
http://www.formsPlayer.com/
Received on Friday, 11 March 2005 18:17:39 GMT

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