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

WOW,
	impressive example form!
I often forget some of the things xforms should do because I 
use Chiba which doesn't support everything yet.

Jason.



From:           	"Mark Birbeck" <mark.birbeck@x-port.net>
To:             	"'Ian Hickson'" <ian@hixie.ch>
Copies to:      	<www-forms@w3.org>
Date sent:      	Fri, 11 Mar 2005 18:16:51 -0000
Subject:        	RE: XForms Myths Exposed - By Ian Hixie (Opera)
Forwarded by:   	www-forms@w3.org
Date forwarded: 	Fri, 11 Mar 2005 18:17:41 +0000

> 
> 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/
> 
> 
> 
> 

-- 
Jason Eacott
Hardlight Interactive
http://www.hardlight.com.au

Support bacteria - they're the only culture some people have.

Received on Friday, 11 March 2005 23:42:57 UTC