Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
The Internet

W3C Releases XForms 31

Posted by timothy from the own-your-own-mint dept.
An anonymous reader submits: "On the heels of several other releases, the W3C has released XForms as a Candidate Recommendation. Coverage here and here. XForms is the way-better version of HTML forms -- it's XML-based and includes built-in client-side validation and calculations, without scripting. It is expected to replace old-fashioned HTML forms in XHTML 2.0. It's also being viewed by many as the standards-based alternative to Microsoft's XDocs. Now's your chance to try it out and submit your comments, before the official Recommendation comes out in a few months."
This discussion has been archived. No new comments can be posted.

W3C Releases XForms More

W3C Releases XForms

Comments Filter:

  • uhmmmm (Score:2, Interesting)

    by ivanandre ( 265129 )
    Very interesting, and useful too for us web developers... but its the standard besides Microsoft standard...

  • XForms? (Score:3, Interesting)

    by gaj ( 1933 ) on Wednesday November 13, 2002 @01:42PM (#4661636) Homepage Journal
    This should make the folks over at XForms [std.com] happy! Isn't it neat the way we reuse names?

    I thought that XForms was pretty much moribund, mostly caused (IMHO) by the "only free for non-comercial use" license. It appears that I was wrong, though. In fact, it looks like the soon to be released 1.0 will be licensed under LGPL. Too bad about the name clash, though.

  • But please... (Score:3, Interesting)

    by Anonymous Cowdog ( 154277 ) on Wednesday November 13, 2002 @01:55PM (#4661766) Journal
    Developers, please refrain from making validation so anal that it becomes unusable. People like Jennifer 8 Lee (NYT reporter) should be able to enter their name into a web form name field, for example. And sometimes people want to enter letters into phone number fields, for valid reasons (like spelling a phone number to help the recipient remember it, or to make a point). Please don't make things too restrictive.
    • And sometimes people want to enter letters into phone number fields, for valid reasons (like spelling a phone number to help the recipient remember it, or to make a point).

      When I ask for a telephone number, I don't want the sender to make it easier to remember or "make a point." I want their telephone number. Heck, if I'm storing it in a database as an integer, allowing them to enter text will just result in a blank data value in the database. Whoops.

      Jennifer Lee won't have any problems entering her name without the middle name, and she could just put Jennifer Eight Lee if she really wanted to.
      • When you store "something" as an integer that means that you want to perform arithmetic operations on it. I don't think that adding, or substracting phone numbers will bring you something :)
      • > When I ask for a telephone number, I don't want the sender to make it easier to remember or
        > "make a point." I want their telephone number. Heck, if I'm storing it in a database as an
        > integer, allowing them to enter text will just result in a blank data value in
        > the database. Whoops.

        That's something that really bugs me about forms that require a phone number with only integers.

        What's my phone number? Is it what my neighbour would dial? Is it what someone in a different
        city in the same country would dial? Is it what you, the person asking would have to dial -
        which I'm very unlikely to know?

        When I fill in my number I indicate that it's an
        "international" number with a +
        In my case +64-9-xxxxxxxx
        to indicate that it's New Zealand(64) - Auckland(9) - number

        As far as I'm aware that's a standard.

        if I don't put the plus, the number is pretty much useless to you. Most web forms don't seem
        to let me put it.

        - Muggins the Mad
      • Given the way you have written your email address ({moc.zoyajeec} {ta} {jc}), I am surprised about your reaction. When submitting my email adress, I often try to add a suffix "+slashdot" (for example "arve+slashdot@some.domain.org") or similar to enable some tracking of where the adresses are distributed, since my mail server apparently supports that. It is not unusual that this perfectly legal email address is refused.

        Furthermore, I live in Sweden and our addresses look nothing like US standard adresses. This is almost often troublesome. Recently, I was forced to enter a state even though I elsewhere had submitted "Sweden" rather than "USA" as country. (I chose Alaska!)

        The list goes on. Most often, overzealaous validation is simply wrong. I todays global society, it is simply too hard to know every acceptable format, and you are better off being a bit relaxed about it. "Jennifer 8 Lee" is a perfectly valid string in a database.

        • Given the way you have written your email address ({moc.zoyajeec} {ta} {jc}), I am surprised about your reaction.

          That's Slashdot's automatic anti-spam formatting, it changes weekly.

          Furthermore, I live in Sweden and our addresses look nothing like US standard adresses.

          Any site that deals with international visitors should be prepared to handle them. If it's not, that's not a validation problem - that's a problem with the company not understanding their customers. It's a completely different problem.
    • Well, is there a guide to the types of input that we should use certain validation schemes on?
    • And sometimes I feel like providing GPS coordinates for my mailing address and an MP3 of modulated tones for my phone number, but that doesn't mean I should be accomodated in most cases.

      Poorly implemented validation, to my mind, would be not letting someone use hyphens in their credit card number or rejecting any and all zip codes that don't include a zip-plus. Asking that Jennifer 8 or The Symbol Formerly Known As The Artist Formerly Known As Prince partake of the alphabet every once in a blue moon, on the other hand, seems like a rather reasonable request.

      • I strongly disagree with what you're placing in here. Client validation should be a *handrail*. It is intended to do nothing more than help the user not accidently enter a data field in a format that the server will reject, like July 30, 2002 instead of 7/30/2002. It should never fail on potentially valid data. You want heavyweight validation, use the *server*. (Matter of fact, client-side output should never be trusted, as more and more "web programmers" seem to think is a good idea).

        If someone wants to enter a bogus name, they're going to do it. Overzealous "validation" is a PITA for a bunch of people. Why do it? Your "checking" above doesn't help security or the integrity of your database in the least. Now, I will grant that if someone *accidently* writes a sentence describing themselves instead of their name in the name field, then indeed, your solution would have caught something that mine would not have. However, I'm quite dubious as to the value of this (how often do people make mistakes like this?), but I'm quite certain that Jennifer and Prince are not tremendously thrilled with your refusing to accept legal names.

  • Interesting thread @bugzilla (Score:3, Informative)

    by an_mo ( 175299 ) on Wednesday November 13, 2002 @02:34PM (#4662149) Journal
    An interesting thread to read is here in this mozilla bug [mozilla.org]
  • ...includes built-in client-side validation and calculations...


    Never trust the client to do validation of data!!!! How do you think people cheat at quake etc etc... it's 'cause the final calculation is not done in the server!!!

    Thank you.
    • Yes, you can do client validation. This will reduce bandwidth when someone misses a field in filling the form, or puts letters in the phone number, or whatever. However, this should not be the only validation. Instead, the client should be used for initial validation, but the server should validate again before acting on the data.

    • Re:Nonono.. don't client validate! (Score:2, Insightful)

      by Anonymous Coward
      Never trust the client to do validation of data!!!!

      Of course not. Just because you don't trust the client doesn't mean you don't let them. Client-side validation is for the benefit of the client. The nice thing is, now that validation is in the form definition, you can use the same definition to perform the server-side validation as well.

    • Re:Nonono.. don't client validate! (Score:4, Insightful)

      by Spy Hunter ( 317220 ) on Wednesday November 13, 2002 @05:02PM (#4663670) Journal
      You still validate the data on the server. Duh. The idea with client-side validation is that the browser can tell the user what's wrong with the form while they're typing in the data instead of after they hit the submit button and get a form page back with big red text telling them they did it wrong.

Slashdot Top Deals

To communicate is the beginning of understanding. -- AT&T

Close