| home / programming / javascript / j_s / column6 / 1 |   [previous] |
|
|
|
There is not much difference. XForms requires its XMLNS namespace declarations
at the beginning of the XHTML file. The HTML <form> tag has now become
an XForms <model> tag which moves to the <head> portion of your
HTML file. But the action= and method= attributes are the same. As for the form
fields, they are roughly the same with inner <label> tags now associated
with text labels for any XForms control. But even the controls are remarkably
uniform.
Here is the list of XForms and then HTML Forms equivalents:
| input => text or numeric data entry | <= input type='text' |
| secret => password protected input | <= input type='password' |
| textarea => multiple line text entry | <= textarea |
| upload => file upload entry | <= input type='file' |
| trigger => respond to click event | <= button |
| submit => submit form to server | <= input type='submit' |
| select => select 0, 1 or many | <= select multiple and checkbox |
| select1 => select 1 only | <= select and radio |
| range => select from numeric range | != No HTML equivalent |
| output => accept external data | <= input type='text' read only |
So what are XForms users getting?
Well, XForms proponents will argue that developers are getting three major benefits with XForms. First, XForms provides a closer tie into XML because data displayed and returned is in XML format, therefore end-to-end XML processing is possible with XForms. Second, because of the provisions of XForms, XSD and XML, much less scripting is required than in HTML Forms. XForms proponents liken the situation to Referential Integrity, Triggers, and Constraints as part of SQL declarations obviating the need for elaborate sets of stored procedures in the database world. Third, XForms uses XPath, XSD, and XSLT - well defined XML components as opposed to a mishmash of scripting (PHP, PERL, JavaScript, etc) as in the case of HTML forms. Finally, XForms are device independent - PDA, mobile phone, or PC; XForms has standard protocols for working on different devices with maximum usability and minimum reprogramming.
As if to pick up on the latter argument, Oracle has developed an XForms browser plug-in that demonstrates the use of XForms in mobile and PDA’s, as well as in PC environments. But interestingly, both start-up Chiba and IBM (in its AlphaWorks XForms development centre) have chosen to use Java as the driver for developing XForms based apps, which in turn use XSLT, XSD, and/or XPath to generate XForms with most of the validations and event handling done within XML.
This approach depends on sophisticated code generation in the front-end design step. In addition, JavaScript is still required for more sophisticated business rules and validity checks on the client. But the advantage (according to Novell, Oracle and Q-Link) is that XForms moves to other devices with greater ease than most other UI solutions. In addition, all use XForms to lower scripting requirements. Novell sees SVG+XForms as being used to create a wider array of user extensible controls that are highly portable. Of course, this is the same advantage that Macromedia sees in its MXML framework (used in its new Flex Developer), a front-end that marries XML-specified Flash components with J2EE for easy data bindings and application development. In general, one can see a consistent theme in the use of XForms - it simplifies access to data, especially data already stored in XML format; it makes creation of default or pre-filled data templates more practicable; it eliminates problematic scripting when moving applications and forms cross platform or to any device; and finally, it eases integration with other promising XML technologies, such as SVG for runtime graphics, SMIL-multimedia support, and VoiceXML voice annotation and help.
In short, developers using XForms are teeming with innovation. But there are competing models such as the InfoPath XSLT dynamic form generation approach (notably, form vendors like Cardiff already support InfoPath form-fillers), the Adobe Acrobat XDP compound document approach, or Macromedia's variation with Flex and Flash. It’s hard to predict a winning strategy, especially with the many different approaches to scripting.
Scripting is heavy with InfoPath, mid-range with Acrobat XDP, and lightest with most XForms. As we have said before, scripting is the key. Currently, in order to deliver cross platform and-on-any-device forms and documents, some vendors are currently avoiding scripting and are using XML, XSLT, XPath, and possibly XLink/XInclude variants to deliver client-side dynamic response with a low need for server turnarounds. Adobe and Macromedia have been able to deliver the same using JavaScript with plug-ins and players on a variety of PDA’s and Mobile devices. So watch portal vendors (such as BEA, IBM, Oracle, and Plumtree), or Application vendors (such as Microsoft, Oracle, Peoplesoft, SAP, and Siebel), and see what their approach is regarding scripting, delivering cross-platform and on any-device reports, forms and documents. Those decisions will help you to handicap the likely winners in this Forms Processing race.
Adobe Acrobat/XML Architecture
Acrobat
JavaScript Reference (PDF)
InfoPath
Technical Overview
InfoPath
demo
InfoPath vs XForms
Comparison
Jupitermedia/DevX -
The Secret Life of XForms
XForms
Tutorial for HTML Developers
XForms Workbench from Novell
Jacques Surveyer is a consultant whose theOpenSourcery.com
features tutorials/demos on scripting technology.
| home / programming / javascript / j_s / column6 / 1 | [previous] |
Legal Notices, Licensing, Reprints, Permissions, Privacy Policy.
Advertise | Newsletters | Shopping | E-mail Offers | Freelance Jobs 
Created: March 27, 2003
Revised: March 10, 2004
URL: http://webreference.com/programming/javascript/j_s/column6/1
