Slashdot Mirror
Mozilla Starts Work On XForms
AnamanFan writes "The Mozilla Foundation, with Novell and IBM, announced the formation to implement the W3C's XForms 1.0 Recommendation on the Mozilla platform. XForms is the forms module in XHTML 2, developed by the W3C. The project enables developers to deliver the type of next-generation, rich, portable web-based applications desired by corporate IT. Is this one step away from the corporate world's dependence on ActiveX? We can only hope."
Except with JS and DOM you have to code for two/three/four/who knows how many different browsers. (this is still the case isn't it? been a while.)
The standard also includes a label for every form element, which currently does not exist. This is very useful for disabled people - e.g. blind people, their screen-readers can figure out which text belongs to which form element. This is currently impossible.
You also no longer define the type of formelement (radiobutton, selectboxes,...) the browsing tool chooses the most apropriate system. For graphical browsers radiobuttons may be cool, but for screen readers it may read the form like "choose one of the following", and for small display devices a dropdown-menu maybe better as 2 radio buttons plus their label takes up too much screen space.
To me it makes sense, but I know that I wont use XForms anytime soon. Because there's still companies that have MSIE 5 as the only allowed browser in their IT-policy... Creating a web- application for them still includes crazy html and javascript hacks
Anything can be done, but it will only work in one specific browser and/or one specific version. Basic stuff works with Javascript, but every browsers has another interpretation of the standards...
;))...
However, if only Mozilla supports the Xforms2 standard, not a single site will adapt them. IE is still the market leader (yes, I'm using Firefox, so don't blame me
It's a lot better than it used to be... also with CSS stuff. While we still don't have perfect compatibility between all browsers, and probably never will, you can get working results across different clients with less hassle and headache than a couple of years ago.
Or perhaps, I just got used to it and only use a well-supported subset of code without realizing it... uh. must check. bbl.
Untrue. There's , used like so:
/>
l ab el.html
<label for="textbox" accesskey="t">Input text here</label>
<input type="text" name="textbox"
http://www.htmlhelp.com/reference/html40/forms/
Microsoft's alternative to xforms is infopath. A form of it, or something like it, will be included in Longhorn as microsoft's new web/intnet based API.
Other other major alternatives are:
Flash/Flex from macromedia.
Java applets.
While they are not all the same in the way they work or what they do they all marketed as improvements to the current web forms and a way to bring back alot of the user interface capabilities that were lost with the move to web based applications.
Actually, you have to give the input form an ID, as in:
<label for="textboxfield" accesskey="t">Input text here</label>
<input type="text" name="textbox" id="textboxfield"/>
and your example can be shortened to:
<label accesskey="t">Input text here
<input type="text" name="textbox"/></label>
I have mixed experiences with access keys in real life. IE uses the ALT key for both pulldown menus and access keys, hence ALT-F is useless (in english-language browsers, other key-combinations are used in other languages). Then there are issues with semantics. For example, if a submit button has an accesskey attribute, should we assume that using the access key submits the form, instead of just focusing on submit button?
18 Nov 2003: A preview release of Oracle's XForms processor PlugIn for Internet Explorer is now available. The XForms Processor is a plug to Internet Explorer 6 on Win2000/WinXP. A User's Guide, Datasheet and several samples are provided with the preview release install.
Annoying as hell one:
Have a text field and a hidden drop down. On text.focus() display the drop down.
Search the dropdown as you type (substring on select.option.text and so on).
If the text fully matches or the user just presses enter (or uses the drop down), select the drop down value, hide it and set the text to that of the selected option.
If the text doesn't match anything on the select, then mark as new (hidden field).
As I said, a PAIN IN THE ASS, but I had to do it for a client that was completely used to comboboxes.
From the DENG web site :
"DENG is an open source Modular XML Browser, capable of rendering subsets of XForms, SVG, XHTML, XFrames, arbitrary XML(...) Currently, the footprint of the DENG Modular XML Browser is 76 KByte, allowing zero-install deployment of these W3C standards to the vast majority of today's web browsers that have the Macromedia Flash Player 6 installed."
http://claus.packts.net/
http://sourceforge.net/projects/dengmx
This is a really cute application and for those of you who'd like to see Xforms in action, there's a few working examples on their demo page : http://claus.packts.net/deng/examples
Of course, it's open source (GPL).
I think the major benefit is data validation. With X-Forms, all the information you input on a web page can be checked before it is sent to the server without the need for writing reams of javascript. All you need is a simple xml schema.
>>I wasn't able to turn up a simple useful 'what are the benefits of XForms' document anywhere
h tm l
Errm... did you look at the FAQ?
http://www.w3.org/MarkUp/Forms/2003/xforms-faq.
I work for a large software company that makes CRM (et al) solutions for business that are delivered via web, and use only HTML and Javascript.
From a web site, users do ALL management tasks.
Hmmm, looks like the article is from March 2000, and the referrer software (Mozquito) is no longer at the URL they present. From what I can make out from the article, it used Java to process the pages.
I guess that MS will stick to their ASP, and their integration with IE and ISS. It is a nice solution, and allows one to quickly program certain things, without all the hassle of validation and the such, but it is very restrictive on platform/browser.
As far as I see it, those who want to implement XForms will have to have a Javascript "if"-block on top to decide if they present some XForms or just plain old forms with loads of Javascript to support every single browser and version.
And yes, SOAP would be great. SOAP is the way to go for integrating different online platforms...
There are two classes of application that web browsers are very bad at: rich UI interaction - for example graphics editing - and interactive data apps.
There are workarounds and bodges that can help, but they depend on Javascript and you can't be sure that everyone will be running Javascript, let alone that there is consistency at the DOM level.
There are two things that web applications are very good at: rollout and global availablity. Wouldn't it be great if we could have it all. XForms is a step towards that, targeted at data manipulation applications.
For this sort of application, you very often need to update the information presented, at a field level. So for instance, on a desktop application, you might have a field where you can enter a name, and as you type, another control presents a list of possibilities which dynamically changes. Typing 'S' would show you 'Smith' and 'South' and 'Smart'. Adding 'm' would reduce the list to 'Smith' and 'Smart'. And so on.
To do this properly, you need to be able to have sub-page queries of the web server/web service/database/whatever, or you need to download the whole index and filter at the client (yech). And you don't want the whole page to refresh. So it's not something that HTML as it stands can do, without workarounds.
From the XForms FAQ, here's a list of some of the things that can be done with XForms that aren't possible in HTML:
* Check data values while the user is typing them in.
* Indicate that certain fields are required, and that the form cannot be submitted without them.
* Submit forms data as XML.
* Integrate with Web services, for instance by using SOAP and XML RPC.
* Submit the same form to different servers (for instance a search string to different search engines).
* Save and restore values to and from a file.
* Use the result of a submit as input to a further form.
* Get the initial data for a form from an external document.
* Calculate submitted values from other values.
* Constrain values in certain ways, such as requiring them to be in a certain range.
* Build 'shopping basket' and 'wizard' style forms without needing to resort to scripting.
If you are interested in XForms, it's also worth knowing about Web Hypertext Application Technology Working Group (WhatWG) - http://www.whatwg.org/ who are working on specifying an extensions to HTML to allow richer applications. One of the projects is Web Forms 2.0 which aims to specify form extensions for HTML and XHTML.
Both of these are excellent initiatives which could make the life of web app developers Better.
Mozilla starting work on XForms is terrific. The competition may spur Microsoft on... MS are not very keen on anything that reduces the dependence of users on desktop apps. For them, this is a very sensible strategic position because their income stream depends on continued need for their OS, and that in turn is because applications are bound to their platform. Consequently they haven't been especially fast to embrace (or extend) standards which would make it easier to deliver rich web applications.
Don't bother to weigh in with MS-bashing. You are wasting your time and this is not what the para above is about.
Jeff Veit
Data validation is really that great, you can do it now if you want.
What is good is unwrapping the form from the UI, this should make it easier for small (or large) screens to display the form, and allow blind or handicaped people to navigate the information easier. sections are clear, labels and inputs are tightly bound etc....
thank God the internet isn't a human right.
BTW, if anybody knows Javascript workarounds for Combobox functionality, I'd be very happy if you could post them.
I know there's others out there, but I don't have the time to track them down right now. But...
Combo box
Combo Box
There is a lot of negative talk about XForms, and plenty of people asking what it is good for. I've been following the spec and would like to share why it is useful.
If you have a web application that presents a form, but the server side needs to represent the data in XML, problems abound. Throw in the potential for repeatable elements and a few conditionals in the XML Schema and your simple little form becomes a major pain to develop. I personally wrote a web front end for authoring MODS records and had to do serious JavaScript/DOM acrobatics. The result was good, but compromises were made along the way.
XForms changes this because the form constrains to an XML Schema and sends a populated XML document to the server. This simplifies matters tremendously. It doesn't obviate the need for some serious work to setup XForms, but given my initial experience testing the spec, it is a great step forward.
It is overkill for a basic form, so I hope there are some provisions in XHTML for backward support.
-- Solaris Central - http://w
Is there anything that can't be done with a little JavaScript
Yeah, you can't do dynamic content on a browser that has java script turned off.
Also you can't write code (easily) that works for JScript, Javascript and who knows what BS language will replace javascript in Longhorn.
I tried for 5 years to come up with a clever sig...only to realize that I am not clever.
I don't know about your setup (on what OS are you?), but for me the updagrades were 100% painless, once I set up 0.9, with every update I had no rpoblems at all. That includes extensions, themes, custom profels and plug-ins. And the update problem (that you have download a the whole installer over again) is solved (as per bugzilla).
How many people does even 1% of the browser market represent?
Approximately seven million three hundred thousand.
What you are saying is akin to saying that the citizens of Norway are not 'significant'.
Norway has about 2.9 million internet users, less than half of one percent of all internet users.
I'll let you draw your own conclusions about significance.
You seem to have forgotten the link; could you provide it, please?
[...] my compoany has invested a lot of training time and development in a terminal based solution that works for our needs [...] Why is it better? Why does it cost less? Why does it cost us nothing to replace existing apps? Why will we be able to use it in 10 years from now? Why will our staff be more productive?
Ok, let's take those one at a time (I'm assuming that by "terminal based" you are refering to something even more archaic than ActiveX-based form builders):
Why is it better? Well, for starters, it's portable. Portability always sounds a tad useless because you can't see yourself moving to a different hardware or OS platform, but while that kind of portability is more important than it often sounds, portability is rarely considered in terms of moving between software platforms. Why is it better? Because you can take your forms, defined for application A and move them over to application B for the same purpose (new vendor) or for a similar purpose (say, an inventory control form that you modify only slightly and input into your POS system).
Why does it cost less? Code is cheap. Cost to maintain code (or markup for that matter) is high. Maintaining something that has a public specification and thousands of vendors rushing to support it is cheaper than than maintaining something that is proprietary.
Why does it cost us nothing to replace existing apps? It doesn't. See above (and factor in the change in lead-time to add new features) and perform your own cost analysis. My estimate is that most medium-to-large shops will amortize the cost of such a technology move over proprietary, terminal-based solutions within a couple of years, but that's just off-the-cuff. Talk to accounting, they'll understand what inputs you need for such a calculation quite well.
Why will we be able to use it in 10 years from now? Because XML is extensible, so in 10 years, many new features will have been added, but the old features that you rely on will still be available (though, perhaps some of them will be available in a compatibility mode provided in response to your use of a archaic schema). I'm no XML fan, but I have to admit that this capability is one of its MAJOR advantages over many other alternatives.
Why will our staff be more productive? That one's easy because there are so many answers: 1) Because there is less ramp-up time in learning your environment; 2) because dozens of companies are going to be competing to produce better and better editors and front-ends for such systems; 3) because the fact that you don't lock in your employees to a proprietary system means that they won't be looking to escape from your cul-de-sac and you will be able to retain a higher calibur of employee without having to over-compensate them for their rare, niche knowledge; 4) because, being a modern tool, it will interface well (or be built into systems that interface well) with other modern, high-level tools (e.g. encrypting form access is a trivial after-thought with SSL).
I don't like the IDEA of XHTML and XForms because of the way it changes the character of the Internet, but I do have to admit that for a certain class of business, it's the best option on the immediate horizon.
If you want to see XForms in action, point your browser to XForms Institute
This uses the Flash-based DENG engine, so it should work on any Flash-enabled browser.
The site includes an interactive tutorial, a validator, and the full text of O'Reillly's _XForms Essentials_
.micah
--- Learn XForms today: http://xformsinstitute.com