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

Mark,

Very well written.  Ian, I think he's got you here.  In order for me to
display my XML file in a web browser, I had to custom write JavaScript
code, so I'm familiar with what JavaScript can do, plus, I started
learning HTML way back when HTML 1.0 was the standard, and I can tell
you that a simple HTML form can't do what Mark's showing you here,
unless extensive JavaScript is used and you know exactly what you're
doing.

I've since moved on to XHTML, being cross-browser conscious, and am
impressed with Mark's breakdown of what Xforms has to offer.  (My feet
are nice and warm now, thank you Mark) 


Thank you,

Christopher M Goodrich A+
Corporate Computing Help Desk
Sandia National Laboratories
Science Applications International Corporation
cmgoodr@sandia.gov
(505) 284-4797 

-----Original Message-----
From: www-forms-request@w3.org [mailto:www-forms-request@w3.org] On
Behalf Of Mark Birbeck
Sent: Friday, March 11, 2005 11:17 AM
To: 'Ian Hickson'
Cc: www-forms@w3.org
Subject: RE: XForms Myths Exposed - By Ian Hixie (Opera)


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 21:27:43 UTC