Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Programming Books Media The Internet Book Reviews IT Technology

XForms Essentials 131

Posted by timothy from the left-intentionally-blank dept.
mseaborne writes "So, why should anyone be interested enough in XForms to want to read XForms Essentials in the first place? Well, if you make your living sweating over hot JavaScript and HTML, fighting against technologies never really intended to help you write even fairly simple forms that require such mundane, work-a-day functionality as cross-field validation, data prepopulation, or even reliable data typing; then XForms may be for you. If there are forms you would love to deploy over the Web, but they are too many, or are too complex to even attempt with HTML 4, then for you too, XForms could be the answer." Mark is also an interested party in XForms' success and improvement; he says he "joined the XForms Working Group after all the hard work had already been done." His review continues below.
XForms Essentials
author Micah Dubinko,
pages 240
publisher O'Reilly
rating 9
reviewer Mark Seaborne
ISBN 0596003692
summary Introduction and reference to XForms 1.0

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.
This discussion has been archived. No new comments can be posted.

XForms Essentials More

XForms Essentials

Comments Filter:

  • xforms is intriguing (Score:3, Interesting)

    by prockcore ( 543967 ) on Monday December 29, 2003 @12:52PM (#7828698)
    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.
    • However from what I've seen, it's extremely complicated

      Alternative potential protocols include XWT (xwt.org) and my less-mature pet, SCGUI. The nifty thing about SCGUI is that it does not necessarily require Turing-complete client-side scripting to be usable (it is "declarative" on the client side), reducing virus and trojan horse problems. However, it does not rule out the addition of scripting if security is less of an issue, such as intranets.

      Standards groups should study existing protocols to learn
      • Standards groups should study existing protocols to learn things before starting from scratch. I see no evidence that they evaluted XWT nor SCGUI.

        ???

        The first XForms Working Draft came at the end of 2000, and the Last Call Working Draft in Jan 2002. How much existing XWT and SCGUI protocols was there to evaluate before that?

        Larry

    • Re:xforms is intriguing (Score:3, Interesting)

      by iabervon ( 1971 )
      I think it's mostly just verbose. It's designed in the "xxml" style, where you skip using any useful xml features and use xml tags to represent them. (E.g., you have an item, which has a label and a value. The economical way to do this is to make the value an attribute, since it can't contain markup, and have the label be the content of the tag, since it possibly can. The way they do it is to have a tag, which contains a tag for the label, which includes the text of the label, and a tag for the value, which
    • Now, you may think sounds crazy, but I thought of xml driven forms about a month ago. Today is the first time I have heard of it as a W3C standard! I have a WYSIWYG I have been working on a (oops) MS VB.Net application that has a wrapper to an IE control. The IE control points to a html doc that contains JavaScript drag/drop code. What's nice is the ability to make calls back to the VB.Net application via window.external.foobar (foobar is in VB.Net) The js sets values to the controls for positioning.

  • Tutorial, anyone? (Score:2, Informative)

    by armando_wall ( 714879 )

    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 [w3schools.com].

  • 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.

    • different xforms (Score:1, Informative)

      by SHEENmaster ( 581283 )
      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 t

  • first hand experience (Score:2, Interesting)

    by Anonymous Coward
    teaching procedural programmers declarative programming is very challenging. In fact, it's very very difficult and requires a lot of work. I hate to bash VB guys, but over the last 2 years I've had to explain declarative programming to a lot of programmers. Strong java programmers seem to get it very quickly and generally a couple hours to get a firm grasp of the core concepts. VB programmers on the other hand have a much steaper learning curve and often ask questions like, "how many functions calls would i
    • I hate to bash VB guys, but over the last 2 years I've had to explain declarative programming to a lot of programmers.

      It depends on what you mean by "declarative". All those 2-column property grids in VB are declarations. Most VB'ers are reasonably well versed in them. HTML is also a declarative language, so is SQL.

      • Re:first hand experience (Score:1)

        by Anonymous Coward
        SQL is not declarative.

        It is a bastardization of the TRC and RA, and unfortunately falls short of being a truly declarative relational language.

  • XForms look very interesting, but ... (Score:4, Insightful)

    by jpkunst ( 612360 ) on Monday December 29, 2003 @01:11PM (#7828840)

    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 care not up until Mozilla Firebird and Mozilla support it. Then I'll start caring. As a web designer who does all personal stuff, I have the luxury of sticking to W3C standards all the way, and if Mozilla is the only one that supports them, then that's what I'll use. For the same reason, I haven't worked to hard on XUL. Not that it isn't great for what it's designed for, but I won't use XUL on a web page, shutting out fully compliant browsers (after all, XUL isn't W3C!).
    • There are already quite capable plugins out there. http://www.w3.org/MarkUp/Forms/#implementations IIRC ive tinkered with Mosquito, FormsPlayer and Xero. Although PDF hasnt been natively supported in browsers, it hasnt stopped its widespread use on the web.
  • 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 thi

  • Validation and the GUI (Score:5, Insightful)

    by RetroGeek ( 206522 ) on Monday December 29, 2003 @01:16PM (#7828870) Homepage
    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!

    • Re:Validation and the GUI (Score:4, Insightful)

      by Abcd1234 ( 188840 ) on Monday December 29, 2003 @01:32PM (#7828989) Homepage
      No matter how much the browser will do, you still need to validate the entered information at the server.

      Well of course. No one in their right mind would suggest that the client should do all the data validation, and the server none, for the exact reasons you gave. However, your argument is probably a little too strict, in that it is perfectly allowable to have a great deal of the data verification occur in the client, with the server only performing the final verification step before committing the transaction.

      In addition, you gave the exact reason why client-side validation is good: it can "provide quick feedback to the user, and/or update GUI displays", which takes load off the server side and reduces the amount of network traffic involved in the transaction, while at the same time improving useability, since you don't have to make multiple transactions to perform every single operation the user might wish to perform.
      • Instead of lots of tedious dicking-around type code at the server side, you simply validate it stricly, and dump the whole thing if it's incorrect--because if it's incorrect, it because of serious error or someone trying to play games with your site, rather than forgeting to fill in a field, or enter an invalid e-mail address etc.

        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 s

    • 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 validatio

    • Re:Validation and the GUI (Score:4, Interesting)

      by prockcore ( 543967 ) on Monday December 29, 2003 @01:39PM (#7829058)
      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.
      • Two of the nice things about XForms (for anybody who writes HTML forms today) are (well, will be):

        1) information is submitted as an xml document... which means you can structure info as opposed to HTML forms' "flat" name-value pairs. Given the great tools for validating and manipulating xml structures in memory, this means less (and simpler) code (both validation and "business" processing) on the server side.

        2) Xforms offers more elegant solutions to the behaviour vs. appearance issues of HTML forms. Chan

      • For usability you should avoid popping up a message saying to the user that they got the date wrong. Javascript date popups are so much friendlier for the average user (either attached to a read only text field or a read write one to allow advanced users to tab through fields and enter manually).

        You should try and make it difficult for the user to enter invalid data in the first place, as well as popping up messages to indicate the wrong data has been entered.

        From a quick glance, XForms seems an exc

      • 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.

        Easier from what perspective? To do validation at the client I need to code essetially the same logic twice. Once at the client, then the second time (in a different language) at the server.

        I am lazy. I prefer to code once.

      • So people without client side scripting are all hackers? Strive to be nice with the server side validation as well, although I could understand this being one of the last places you'd want to invest programmer effort.

    • Re:Validation and the GUI (Score:5, Informative)

      by ThatDamnMurphyGuy ( 109869 ) on Monday December 29, 2003 @02:12PM (#7829325) Homepage
      No arguments there. But what XForms ALSO brings to the table is the fact that if done right, you can use those same XForms/XSD documents/snippets to generate or run the server side processing code as well.

      Client side forms + validation PLUS server side validation all form the same drops of XML shared on the server.
    • 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.

      That's exactly the point of XForms. It allows you to specify validation in a declarative fashion, using XML Schema and simple XPath expressions. These same validation declarations can be used on the server side, and indeed, can be programmaticaly derived from existing constraint
      • These same validation declarations can be used on the server side, and indeed, can be programmaticaly derived from existing constraints.

        That would make sense then. You only need to create the checking code once, then have some engine generate the required code for both the client and the server.

  • XForms in Mozilla is not coming soon (Score:5, Informative)

    by nsushkin ( 222407 ) on Monday December 29, 2003 @01:17PM (#7828883)

    There is a long discussion of the proposed XForms support in Mozilla Bug 9786 [mozilla.org]. 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 [formsplayer.com]. 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 [apache.org].

    • There are also server-side XForms modules that render XForms as HTML forms. For example, Apache project lists JXForms.

      Which is probably what everyone will end up using. Hell will freeze over before Microsoft or Netscape get around to implementing existing W3C specs, never mind emerging ones.

      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 t

    • Re:XForms in Mozilla is not coming soon (Score:5, Insightful)

      by po8 ( 187055 ) on Monday December 29, 2003 @03:24PM (#7829867)

      I just read the first few chapters of the book online. They confirm my earlier impression from when some of my students tried to use XForms as a key piece in a project about a year ago: XForms is a classic committee standard. Xforms is too complicated for mere mortals to use, and too complicated for mere mortals to implement.

      I'm not primarily a web designer, but I've built several HTML forms in my life. I found it quite simple, and found workarounds for many of the problems with HTML Forms cited in the text. It looks like it would take me literally a couple of weeks to figure out how to build the same forms using XForms. I don't have that kind of time. Nor, as the parent post implies, do I have the time to get the needed tools working so that anyone can use the resulting forms.

      My students were trying to use XForms to define the GUI of a simple Java app. They ultimately got it to work, but by then, they had burned all the project time they had. They got too deep in the alphabet soup, and couldn't escape.

      I'm neither stupid nor ignorant. I understand SGML, HTML, and XML passably well. If I can't figure XForms out easily, I hold out little hope for the average web designer to do it at all.

  • XForms is doomed as long as it is not natively supported in IE.

    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!

    • Its not free but.... (Score:1)

      by Anonymous Coward
      Intraweb http://www.atozedsoftware.com/intraweb/ might be exactly what you are looking for.
    • Parent post is 100% correct. If there is no IE support, this is as much use as an ashtray on a motorbike, except for hobby uses, or just possibly, deployment of intranet applications to a closed community of users.

      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 our

  • Is this necessary? (Score:3, Interesting)

    by Khomar ( 529552 ) on Monday December 29, 2003 @01:31PM (#7828981) Journal

    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 think what would be a "hit" would be a VB- or Delphi-like front-end to design the HTTP-bound forms. However, this would require a coordinate-based layout instead of the "flow based" layouts often found in web standards. I don't want to start another coordinate-versus-flow holy war here, only to say that I think managers prefer coordinate-based because one has full control over where everything goes. In other words, "the customer is always right, even if they are illogical". Flow-based is more logical, but

      • This is basically what .NET does. It has a graphical user interface that allows the user to place controls either with coordinates or in a flow layout (your choice) and then provide code for the controls using C# or VB.NET for the backend. Whether you like Microsoft or not, they have put together a pretty good toolset for this kind of web development.

  • A confusing name... (Score:3, Interesting)

    by Brian Knotts ( 855 ) <bknottsNO@SPAMcascadeaccess.com> on Monday December 29, 2003 @01:33PM (#7828992)
    Had the people who worked on this never heard of the XForms [std.com] GUI library?
  • Checking out the tutorial here [w3schools.com]

    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.

    • The sample you refer to is a little old. We have a 'Hello, World!' [formsplayer.com] sample on our web-site that shows how to build a simple form that is just as compact as the HTML version. But as you'll see from the tutorial, despite being compact, this form packs a lot of power that XForms gives to the form author 'for free'. And more importantly, by using XForms it provides a foundation onto which user interfaces that are far more complex than those usually built with HTML can be constructed.

      Mark Birbeck
      CEO and CTO
      x-p

  • Using standards saves time (Score:3, Interesting)

    by October_30th ( 531777 ) on Monday December 29, 2003 @01:39PM (#7829057) Homepage Journal
    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.
    • Sounds familiar... didn't you write almost the same comment a few months ago? I don't remember what story it was, something about CSS I guess.

      Mind you, I'm not complaining. Your comment is on-topic, informative and perhaps also insightful, and even if I'm right and you posted this before, you're still much less redundant than the /. editors.

  • If on line text is any indication ... (Score:3, Interesting)

    by jc42 ( 318812 ) on Monday December 29, 2003 @01:40PM (#7829061) Homepage Journal
    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?
  • While XForms may have its place, a much more useful and practical extention to standard HTML forms is Webforms 2.0 [hixie.ch]. 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 [hixie.ch], Webforms
  • 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.
  • 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.

  • concise (Score:4, Funny)

    by Clover_Kicker ( 20761 ) <clover_kicker@yahoo.com> on Monday December 29, 2003 @02:04PM (#7829261)
    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.
    You sure used a lot of words to describe how compact the book was.
  • The final chapter covers extending XForms. At the moment this mostly means how to use scripting with XForms.

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

  • 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.
    • You need to understand that XForms is not a client only technology. J2EE or .NET application server runtimes can take XFORM documents and render them using HTML 4.0, CSS/JavaScript. The key is that the FORM designers can use simple tags to create rich self validating forms that can then drive Web Services. This will remove the need for JSP/Servelts or ASP.NET ASPX files. So please get over "The browser doesnt support it". Just think if you are a large organisation will a lot of self maintence service forms
      • If you can use XForms server side from J2EE or .NET, and output HTML 4, that's marvellous, I would certainly use them that way.

        However, there does seem to be a lot of noise about client side XForms, which makes me wonder as to the sanity of the beast. I don't think it's reasonable to expect browsers vendors to implement every new fad originating from the W3C crowd. It's taken us so long to get to the stage where, by and large, most browsers support HTML 4, some part of ECMAScript and CSS 1.
  • 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 [std.com] is a X11 toolkit that is featureful and free for non-commecial use.

    Why could they have called it XMLForms or XWebForms? oh well.

  • Why just forms? (Score:3, Interesting)

    by LS ( 57954 ) on Monday December 29, 2003 @05:14PM (#7830804) Homepage
    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
  • 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
  • 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 fe
  • There's a nice alternative to XForms that's working today on most browsers - The qForms JavaScript API [pengoworks.com]. Easy to use and open source under the GNU Lesser GPL.

    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.

Slashdot Top Deals

We must believe that it is the darkest before the dawn of a beautiful new world. We will see it when we believe it. -- Saul Alinsky

Close