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.
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.
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'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
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?
While XForms may ease the minds of some, anyone who trusts client side validation is kidding themselves
On smaller intranets it may be okay, since the chance of users being devious hackers is rather small. However I agree that ideally the server should also check. Ideally the declaration of what the validation should be should go on the server, and that validation is automatically echoed to the client script/XML also, so that both client and server checks. The key is to only have to declare the validation in one place and then have the framework implement it on both sides.
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!
JavaScript is a crappy validation language. It has no built-in Trim function/operator, for example, and date checking requires too much object instantiation and reg-ex's. Make it a damned single isValidDate function, for petesakes.
Table-ized A.I.
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 matter how much the browser will do, you still need to validate the entered information at the server.
True, but that's no reason not to validate at the client. It's much easier to let the client pop open the little warning dialog letting the user know that they screwed up the date for example.
It's the whole user-friendliness part that makes form building such a pain in the butt. You basically have to build each form twice. The initial form, and then an error-version of the form which lists what they screwed up, and pre-fills in all the stuff they didn't screw up so they can fix it.
What we do now is such a horrible hack.
So for user-friendliness, client-side validation.. then on the server side we just do a quick validation and if there are any errors, it's because the client is trying to break us, and we just spit out a warning page that says "error".. no need to be friendly.
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.
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 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