Slashdot Mirror
XForms Essentials
The motivation for XForms came from a realisation that the Web has pretty much ignored the needs of forms-based sites up to now, beyond the simplest and most trivial of uses. That more complex forms do exist on Web sites today says more about the ingenuity of their authors than about the utility of HTML forms. XForms is designed to make form authoring, maintenance, deployment and redeployment to different platforms, work.
XForms removes the need for reams of script to make a web form function. No longer must you code business (or any other sort of) logic right into the UI. Instead, you write rules against the XML data structures you want forms to populate (that's right, data structures, not name value pairs, unless that is actually what you want). XForms lets you bind the UI to the data structures directly (or indirectly, if you want to be really clever). The UI responds to changes to the data, rather than the other way round, and suddenly life really does become much easier. Granted, you must first make the mental leap from a procedural to a declarative frame of mind, but once that is achieved you will soon be reaping the benefits.
Rather than pontificate on the wonders of XForms (and I am biased, being a Working Group member), I would urge you instead to take a look at Micah Dubinko's book. (Micah is even more biased than me, having been a Working Group member for much, much longer.) No purchase is necessary; you can read the full text online, though I will admit that even I did end up getting the hard copy eventually. The book is small, and paper still has something over HTML, even when viewed on an Apple PowerBook.
Given that you can read Micah's book on the web, I really would urge people to look at it before attempting the rec. itself. The intended audience for the XForms rec. is the XForms implementer, rather than the XForms author. So, short and well-written as it undoubtedly is, this is not an easy read. If you are not sure how much time to invest looking at XForms, you could do worse than read the first chapter of Micah's book. It explains why XForms is as it is, and how it got there. It lays down the principal problems with HTML forms, and explains how XForms is better.
Having roused your curiosity in Chapter 1, the second chapter works through an example form. It introduces the reader to XForms functionality, and points to the ways in which XForms is built on a foundation of much-loved and popular W3C recommendations, such as XPath, XML Schema and CSS. Fortunately Micah does not assume that the reader is fully conversant with these technologies; he has written very serviceable introductions to them in subsequent chapters.
Most of XForms Essentials is a reference to the XForms recommendation, with enough examples and usage notes to make entries useful to beginners and old hands alike. Micah provides tips on how to get the most out of XForms, and how to miss the most common pitfalls: for example, how to avoid the need to write complex XPath expressions. There is even a dedicated troubleshooting chapter which people will probably find invaluable, for a while at least. However, as your forms become more ambitious, you will probably hit problems not dealt with by Micah. I think this is inevitable, given the youthfulness of the standard and its implementations. Micah has said that he will update the text as necessary. People should watch his blog site to see what Micah adds.
Micah's text is concise and pithy throughout. Consequently, one of the chief virtues of XForms Essentials is that it is short. To be fair, this partly stems from the conciseness of the XForms recommendation itself. However, it is also an indication that some topics are only covered briefly. For example, there is very little mention of security issues. XForms Essentials certainly doesn't tell you how to deploy forms onto the web. I suspect that some omissions result from the lack of a body of XForms deployment experience as yet as much as from a desire to keep the book short and focused. Micah does, for example, make some useful suggestions about authoring best practices, but these are necessarily sketchy. They do get you thinking, though, about the possibilities opened up by XForms.
The final chapter covers extending XForms. At the moment this mostly means how to use scripting with XForms. I suspect that people initially drawn to this section will ultimately not find it nearly as useful as they first thought, as XForms really does remove the need for most scripting. However, it would be ridiculous to suggest that scripting does not have its place in web development, and Micah suggests what that place might be.
Micah has combined several functions in this book. XForms Essentials answers the question of the moment, "Why XForms?", and so helps to justify interest in yet another W3C recommendation. It is a very good introduction to XForms for the complete beginner, and a handy, desktop reference for the everyday author. You may only read the outer chapters once or twice, but the core of the book will remain invaluable.
What is really missing from the book is any good information on XForms implementations. This is fair enough, the book will remain useful as implementations come and go. However, Micah has written an article describing ten XForms implementations. The article is up-to-date enough to be very useful. The fact that Micah was able to find ten implementations already speaks volumes for the interest generated by XForms (as well as suggesting that the spec is quite implementable). Please bear in mind that Micah's list is selective, not exhaustive!
I have now spoken to a number of people new to XForms (as are we all just now), many of whom use Micah's book, and all report that it is a useful resource to have around. Every one has ended up buying it in the end.
Mark Seaborne works as a technical architect for Origo Services Ltd, the XML message standards body for the UK Life Insurance Industry. When your eyes get tired, you can purchase XForms Essentials from bn.com. Slashdot welcomes readers' book reviews -- to submit a review for consideration, read the book review guidelines, then visit the submission page.
xforms is indeed intriguing and anyone developing a complicated web tool could find this technology a godsend. However from what I've seen, it's extremely complicated (on the scale of p3p) and difficult to use.
Right now, I don't feel like I have the need to use them, but it's better to be prepared.
You can find a tutorial on XForms here.
I tried to find the source code to Xforms-1.0 (libforms.so.1), but the download page says it was pulled for some reason. I need it for a LyX upgrade.
When all else fails, run.
Declarative programming is very powerful, but the biggest challenge is teaching programmers to think declaratively. That isn't always the easiest task and often some programmers just aren't capable of understanding it.
Is there equivalent functionality to XForms in the ASP and .NET space? Or is there support for XForms in .NET/ASP already (I don't see any)?
Thanks!
Standards from 5 or 6 years ago? 5 or 6 years ago "HTML Standard" was an oxymoron. I personally don't use IE but, aside from the MS proprietary quirks, IE seems to do as good a job as any browser when it comes to handling standards, and one of the reasons it took over the browser market (other than, of course, being bundled in Windows), is the long-time lack of another appealing solution since the inital versions of Gecko were slightly disasterous (and the others didn't hold enough ground).
I'd say that it probably will take a while for XForms to become standard but it has mostly to do with the combination of the net still emerging from the past lack of standardization, and more importantly the fact that in an environment where millions of users whom you don't control access the page, you should try to accomodate as many people as possible. Since a large number of people don't stay on top of upgrading their browsers that normally means using relatively old, trusted technologies (or writing alternate versions of everything).
I don't try to be right, I just try to make people think
I suppose we will have to wait for widespread browser support before we can use them in web applications. And I'm not holding my breath for that to happen, especially with Microsoft putting IE development on hold.
I think we will have to make do with the <form> tag for the foreseeable future.
JP
I think XForms is a technology that is long overdue. The blending of form and presentation, along with a lack of reusability in web forms is something that should have been solved long ago. HTML just does not make a good UI for complex applications.
That all being said, there is absolutely no incentive for Microsoft to support this or any of the other useful W3C standards in IE. In fact, it is in their best interest not to. Until IE supports this, only 3rd party plugins can let web designers utilize this technology. Unfortunately, many companies refuse to allow the installation of plugins that are not blessed by MSFT or are not ubiquitous (e.g. Acrobat Reader) This means that web applications must wallow in the dark ages, or use MSFT backend that plugs into IE specific hooks on the browser, basically giving MSFT end-to-end.
It's closed source, and the savanah download page is still down. This is a different Xforms than the one the article is about.
I email Angus Leeming, and he replied with:
The savannah site was hacked some weeks ago and the savannah guys took everything offline in order to rebuild the site in a safe manner. They have been gradually returning the site to its former status. I think that the download page is the only remaining victim.
I'll get on to them and ask them for a progress update.
You might try Debian/Sid; it contains xforms for my LyX install. I'm looking for the Solaris build; email sheenmaster at osnippets.org if you come across it.
You can't judge a book by the way it wears its hair.
No matter how much the browser will do, you still need to validate the entered information at the server.
While XForms may ease the minds of some, anyone who trusts client side validation is kidding themselves. So yes, while it might be easier to format the forms, and you have easier client side actions and validation, you cannot really trust the information when it arrives at the server. All the same validation must be performed again.
Because people WILL hack the data stream and try to insert bogus information. The one thing that they CANNOT do is corrupt the server side business logic (short of hacking the server, in which case you're hooped anyways).
The best that client side validation can do is provide quick feedback to the user, and/or update GUI displays (such a totalling a column of numbers for a shopping cart).
I once subverted an input form which insisted that I enter a name. So I looked at the Javascript and found that it was testing for an empty string. So I entered a space, and the site let me in!
- - - - - - - - - - -
I am a programmer. I am paid to produce syntax not grammar. Deal with it.
I'm not sure this is fully troll. The AC raises a good point, who will use XHTML2? IE's next version is tied to longhorn, and since both it controls the market, and that longhorn aint out for another 2 year's, that's a lot of time to wait.
The value of the XHTML standard for general use, is also questionable. A lot of old mum/dad user's are still using AOL3, with IE3/4 who cant display XHTML, and the only real differences is tighter control on syntax, rather than any tangible benefit's, (like more tag's / attributes, or something cool like CSS), it's also more confusing to the new webprogrammer, and waste's several additional bytes on common tags.
As for XForm's, I cannot comment - but if it's tied to the XHTML standard, then I suspect it's going to take at least half a decade to materialise.
-Adam
#!/bin/csh cat $0
There is a long discussion of the proposed XForms support in Mozilla Bug 9786. There are 460 votes for this bug, however the support is not forthcoming. Basically, there is no one willing to implement XForms in Mozilla because XForms has too many dependencies on other XML modules that are not implemented in mozilla.
If you are developing only for IE6, you can use a commercial formsPlayer component. I tried their demo, it looked decent.
There are also server-side XForms modules that render XForms as HTML forms. For example, Apache project lists JXForms.
"and the others didn't hold enough ground" - meaning other browsers not other versions of Gecko or Mozilla. Obviously the browser only handles (and can only mangle) what it sees, so the old technology comment applies only to client-side scripting.
I don't try to be right, I just try to make people think
PNG? CSS1? CSS2? All W3C standards that IE doesn't implement fully or correctly, rendering them partially useless.
If Microsoft refuses to support it, then can there be a third party add-in or plug-in for IE to support Xforms?
I am still looking for "native IE" solution for writing rich web-enabled client apps -- short of hacking gigabytes of ugly JavaScript that is. XUL would be nice!
...but I'm growing a little tired the letter "X".
With all of the tools and libraries that have been developed in a multitude of languages (not too mention the development tools of .NET), do XForms have any real advantage. In just glancing through this book, it looks to be a rather complex process to learn the new paradigm. Granted, with current HTML, it is often a very tedious process to perform validation, etc. However, the work has already been done in the creation of the libraries and tools, and the results work with most browsers. Is there anything that XForms really adds that makes it easier to use than say .NET (not too say that .NET does not have its own issues)? As another poster pointed out, we will have to wait for browsers to begin supporting this technology anyway.
It also seems to me that a lot of this work can be handled server side as well, and this may in fact be easier to work with than relying upon the compatibility of browsers. Are XForms simply too little too late, or is there really some inherently great thing that they possess that our current tools cannot do?
I believe in de-evolution. God made the world perfect, man fell, and its been going downhill ever since!
Had the people who worked on this never heard of the XForms GUI library?
Well let's take a look at what technologies IE supports reasonably well.
HTML 4, spec first published Dec. 18, 1997
CSS 1, spec first published Dec. 17, 1996
CSS 2, spec first published May 12, 1998
So they range from 5.5 to 7 years old.
Also, I find it offensive to hear someone say that IE handles standards as well as any other browser. Maybe as well as any browser available at the time IE 5 was released, and it has progressed very little on it's way to version 6. Please see this for a small sampling.
Checking out the tutorial here
I find that simple example is clean in straight forward in html but significantly more verbose and convoluted in XML/Xforms. I guess I am always suspicious of technology that makes things harder to do simple things.
Our faculty of the university at which I work has decided on a new layout for their web pages. This was done and delivered to us by a PR agency. I feared that it might be bad, but that fear didn't even come close to what I had to witness.
Imagine having to tell our users (many of which are using GNU/Linux or Macintosh) that our web site only works reliably in Windows with Internet Explorer 6.0 and above. Just because a PR agency can't develop web pages. It's impossible. I had to do something about it.
So when I implemented the layout for our department (scheduled to go live later this month), I scrapped everything they had done. I took a printout of their page (as it looked in Internet Explorer) and marked up what colors and fonts they had used.
Then I set down and wrote the same thing using XHTML/1.0 Strict and CSS1. This was about two days work, but the finished result now validates using w3c's validate tools, and it works reliably in all browsers I've managed to try, all the way back to Mosaic and Netscape 3, with or without images (yes, Lynx, Links, w3 and other text browsers work very well indeed too).
Not only did I get the pages to validate. By using CSS, I was able to get rid of several images they had been using with their design. The overall size of a page, including graphics and CSS, now weighs in at about 35 kbytes. This is compared to around 120 kbytes with the proposed code.
And even better, most things can be cached by the browser (CSS code and images). The only thing that needs reloading when you hit subsequent pages is the dynamic XHTML code, which weighs in at around 5 kbytes, compares to 40 kbytes in the proposed code.
Now, I think our students will like us. This result is even better than the pages that we have today. They render quickly and effortlessly even on old equipment or on extremely slow links.
I havn't been able to convince the faculty to make my code the "default" yet, but they might get the idea once people start noticing that our pages load much more quickly than the rest of the faculty pages.
So, using standards isn't always about making things render nicely in all browsers. It gives you a while heap of nice side effects that isn't worth sneezing at.
The owls are not what they seem
No purchase is necessary; you can read the full text online, though I will admit that even I did end up getting the hard copy eventually. The book is small, and paper still has something over HTML, even when viewed on an Apple PowerBook.
I looked at the online text with my PowerBook, too, partly because I have four browsers there. If the result indicates anything about the project, I'd say they aren't quite ready for prime time yet.
All four of them displayed the various <div> chunks so that their text overlapped, though in different ways. This was probably in part because, to fit them all on my 17" screen together, I had to make them rather narrow. But I do this routinely, because I always need several windows on the screen at once, and text that's formatted in 100-char lines isn't all that easy to read. (At least the doc doesn't force the page width with a width= attribute.;-)
Internet Explorer was the worst. This was mostly because the backgrounds were all solid, so that overlaps made the covered-up text invisible. The boxed text often had horizontal lines through the text, due to bad line breaking.
Safari was very similar to IE, but the formatting and line breaks were somewhat better. There were still headers messed up by horizontal lines.
Mozilla and Firebird were the best, and nearly identical. This was mostly because the background of everything except the upper-left doubly-boxed text were transparent, so you could at least read nearly all the text. The headers had even more horizontal lines through the text than IE or Safari.
I might test it on my linux box, which has even more browsers. Or maybe I won't bother. I am tempted to take a look with my PDA/cellphone. That's always an amusing test.
Anyway, this is what should be fairly straightforward text with a few images and hyperlinks. If it comes out on the screen so badly with these common browsers, what are the chances of XForm stuff being displayed sensibly? I can see a lot of problems getting all the common browsers to handle XForm data sensibly. Do they have a scheme for preventing the usual Microsoft variant implementation?
Those who do study history are doomed to stand helplessly by while everyone else repeats it.
While XForms may have its place, a much more useful and practical extention to standard HTML forms is Webforms 2.0. It more or less solves the 80% most common client-side validation tasks without adding a lot of complexity. This is a standard that will be intuitive to the average web developer, who is likely to be able to use it properly with a minimum of fuss. XForms is hugely compilicated in comparison, though it does solve a much bigger problem.
Additionally, according to an Opera developer, Webforms 2.0 has a good chance of being implemented in web browsers (meaning Opera and mozilla, I'd guess).
Learning XForms won't keep your job from being offshored. If you have to use a form, use a form tool, or that pesky HTML that is supported by browsers *gasp*.
If your job really is writing HTML/Java/Forms, you better go learn some more skills and fast.
- Adam L. Beberg - The Cosm Project - http://www.mithral.com/
How is it off topic to state that the technology is practically useless?
Blar.
IE has progressed very little since 5. At that time Netscape hadn't progressed much since 4 (and people had a lot of headaches getting standards to work on Netscape), until it was rewritten and stabilized and Mozilla broke off. None of the browsers yet handle the standards perfectly, even some of the older standards. Looking at the lifetimes of the browsers though, I'd say the next version of IE will determine whether it can be condemned (for standards), which there's a decent chance of since MS isn't much for standards that they don't fabricate.
I don't try to be right, I just try to make people think
Because this point seems to be getting lost on most. It is possible to implement XForms purely with Javascript/CSS and the old FORM tag. So its not the end of the world if IE doesn't support it. We just need a good implementation.
I think the HTML form standard should be tweaked instead of tossed. There are three things that need adjustments to get decent forms in HTML.
First, have the option of not redrawing the page upon submission. If each widget is named, then only send what is different per name. For example {input name="foo" value="123.12"} This would update the value in the EXISTING input box named "foo". (Curly braces used instead of angle brackets to not confuse slashdot.)
Second, have a "grid" widget that allows spreadsheet-like data entry grids.
Third, have validation options such as {input type="text" name="foo" format="number" decimals=2} or perhaps {input type="number" name="foo" decimals=2}
Add it to the list along with cross browser compatible advanced css layout and support for png graphics including transparency, again in all major browsers.
I looked through the implementations and not surprisingly the present strategy for many seems to be to use an intermediary tech, like java or flash, but didn't see anything that was open source AND multi-platform AND available (some non-functional links) AND relatively easy (came across one faq with several potential java problems you probably wouldn't want to annoy visitors with).
But an experienced geek should be able to find something to mess with for a peek at a potential future. That future doesn't seem to be now, but who knows, perhaps this will become reality before png transparency is available in all major browsers.
No, none of them are perfect, but all the current browsers running Gecko, KHTML, or Opera engines are far far superior to IE 6, where things are broken in the most basic ways.
I'm hoping and praying that Microsoft decides to play nice and implement CSS 1, 2, 3 and XHTML correctly in IE 7, because if they go the proprietary route in an attempt to dominate the web it's going to make web development a really shitty job, just when things were starting to look up too.
That happened to me for the first time and guess what. I'm switching to Adobe's closed source reader just to piss you nazis off.
Intraweb http://www.atozedsoftware.com/intraweb/ might be exactly what you are looking for.
The author is a member of the W3C XForms Working Group, so he knows what he is talking about. This guide is a great starting point for getting to grips with XForms whether or not you are already familiar with HTML forms. This is a much better place to start than the XForms spec, which is pretty impenetrable to your average forms author. Micah takes you through the basics, shows you where XForms fits with other W3C standards, and gets you started with authoring. Once you are feeling a bit more confident this book serves as an excellent reference. One of the really nice things about the book is that there isn't too much of it. It gives a good grounding in the subject without any waffle. In the course of my work I have spoken to several others who have similarly found Micahas book to be an essential starting point to XForms, and a solid reference book.
XHTML can be written to work with older browsers, including IE3 and 4. XHTML 1.1 Transitional even allows the usage of deprecated tags, namely FONT. And XHTML discourages bad HTML coding styles. Browsers spend too much time tolerating bad HTML.
.sigs are useless; it doesn't protect you from imposters.
But XHTML2 is entirely different, and is not backwards compatible even with XHTML1. XForms are part of XHTML2.
I often wonder what the W3C people are thinking. I love all the interesting features that appear in things like CSS3. But what's the point if nobody implements them? Some of their effort should be going to lobbying the vendors and/or creating reference implementations.
Geez, how about a spoiler warning next time. You basically ruined the whole book by giving away the ending.
So inconsiderate... How am I supposed to enjoy all of the great, far-fetched fiction coming out of the W3C with these kind of reviewers on /.?
True story.
I do a lot of form-based web stuff in PHP and ASP. The biggest part is oftern the form/validation/feedback stage. Sometimes you look at the code, and you could swear it was the source for some complex C++ (or whatever) program, rather than a simple web page.
Only problem with XForms is: how long will it be untill it's supported widly enough so that we can use it? Then there's still backward compatability problems.
...my god, that's five years.
Xforms ? Javascript ? It takes a lot of imagination to call it a 'news for nerds. stuff that matters' :-(
As a web developer, I have no intention of learning this technology until I am sure it will be supported by all major browsers.
Whilst I am sure that XForms are fantastic and will lead to the eventual extinction of html forms, it is not currently pheasible to use them in web projects. I will continue to use html and javascript today, as web browsers support html forms and javascript today.
In this world nothing is certain but death, taxes and flawed car analogies.
Speaking of which, checkout my website. Fully XHTML Transitional. Not terribly painful to do.
Visit CryptoGnome in his home.
Given that it is possible to write such applications using standard HTML (though no-one would claim it is easy), why on earth would anyone produce this (very much needed) solution in a way that guarantees it will only ever be of academic interest.
We had to build something exactly like this ourselves. It would have cost over $500K in internal costs. It is great, and helps us build our app, but it is pure enabling technology and I would love to be able to use a well-supported framework instead.
But anything that doesn't support IE is dead in the water. Microsoft will do everything in their power to make sure it does not fly on IE.
[x] auto-moderate all posts by this user as insightful
When I first saw the headline I thought it was refering to the X11 GUI Toolkit (that was quite popular a few years back). XForms is a X11 toolkit that is featureful and free for non-commecial use.
Why could they have called it XMLForms or XWebForms? oh well.
“Common sense is not so common.” — Voltaire
I may sound naive here, but I'm curious why this type of work is limited to forms. In fact, why are we still stuck with the "stateless" paradigm? Wouldn't it make sense to create a general GUI frontend that maintains a connection with the server? I know you are thinking Java, but I'm thinking something much thinner than that - just a front end GUI, perhaps more like X windows than Java, but accessible through a browser. There must be something wrong with this idea, or else this would be the direction we're headed, right? The whole document/hyperlink/form thing is so played out...
LS
There is a fine line between being a cultivated citizen and being someone else's crop. - A. J. Patrick Liszkie
I've heard this many, many times before. When I was a web developer, every other article I read was about the NEW REVOLUTIONARY way of writing web apps that would replace HTML/JS/CSS on the client side. Every one of them has flopped. Trotting out the old "W3C" recommendation is a joke, really. When will people learn that the W3C doesn't really have anything to do with the web today? I don't care what whiz-bang technology they endorse; it's going to be dead in the water until users, web developers, and web browsers support it, which at this stage in the game, is a lot of different people. This is getting filed away as yet another cute, yet stillborn web technology.
Transitional? Hah. Wuss.
If 90-95% of the browser market doesn't support Xforms (currently it must be like >3%), then it's pointless to use them. Web browsers are stagnating (w/ exception of mozzilla, kind of). There's nothing that you can't do with web pages now that you couldn't do 5 years ago. I mean, am I wrong, or can Perl & HTML4 (w/ tables for positioning!) still cover 90% of the web sites' needs in existence (look at /., yahoo, ...)? So the Committee finished their standardization. Big deal. Standardizations for a few thousand or million other things across the world were completed that day, too.
XForms sounds great, but as many have pointed out it's useless unless it's supported by the majority of browsers. Now that browsers are a pretty mature technology, people aren't upgrading as often. So I can't see that critical mass of support arriving any time soon.
One of these days I'm moving to Theory - everything works there
yeah, I actually DID wuss out when it came to being fully XHTML strict. Some things were difficult and others I couldn't find a workaround/equivalence for. Mebbe one day I'll upgrade it to strict.
Visit CryptoGnome in his home.
don't have mod points now. But the link in the parent post is valuable!
Bye egghat.
-- "As a human being I claim the right to be widely inconsistent", John Peel
Seriously, there is like a small kernel of tutorial there surrounded by fluffy popcorn.
This site has more reviews for this book.