Friday, May 25th, 2007

fValidator: Unobtrusive javascript tool for easy handling form validation

Category: JavaScript, Library

Fabio Zendhi Nagao, an applied math student and term Moootols fan, has created fValidator an open source unobtrusive javascript tool for easy handling form validation.

You markup your form something like this:

  1. <input id="exA_Phone" class="fValidate['required','phone']" name="phone" type="text" />

And, the framework takes care of the validation. The example will let you see it at work.

Good stuff. My only complaints are that:

  • You should have a way to know the conditions before you try (e.g. required or not)
  • If there are more than one validation on a field it looks verbose (has to be a phone AND required)


Posted by Dion Almaer at 10:22 am

2.8 rating from 68 votes


Comments feed TrackBack URI

Hmm.. sounds alot like fValidate ( which has been around for along time and does the same thing but alot more… Still, all good stuff…

Comment by Richard — May 25, 2007

Why is class=”random properties” more unobtrusive than onchange=”random properties”? That class you got there doesn’t look very “classy” to me…

Comment by Pelle — May 25, 2007

Pelle: +1

Does this validate with W3C CSS validator?

Comment by Sad Developper — May 25, 2007

Interesting idea, but those classes are seriously godawful. Nested quote marks?

Comment by JDP — May 25, 2007

A quick poke at it seems to indicate that it’s yet another email validator that doesn’t bother with trivialities like RFCs, and therefore doesn’t like the “+” in my primary email address.

(And somebody please inform the spammer-and-pedant filter that the “X in Ajax” doesn’t stand for anything. AJAX maybe, Ajax no. Heh.)

Comment by Karen in Wichita — May 25, 2007

There’s nothing wrong with having required and phone, it’s not verbose.
They aren’t mutually exclusive, you can have a form that doesn’t require a phone number, but if it’s there, you wan’t it to conform to proper format. Conversely, you can have a required field without any format validation.

Comment by Jonathan — May 25, 2007

*shameless plug*

I also have a similar form validator here. “Abusing” class as validation rules, but it’s a cleaner one compared to fValidator. Also have a server side companion which not only capable of validating the form at the server side, but also capable of generating needed client script validator. Not to mention works using the same rule (coded separately though, in js and php)

Comment by toni — May 25, 2007

What’ wrong with using XForms, it was designed for doing this kind of validation plus tons more!

Comment by hans blink — May 25, 2007

On the topic of server AND client side validation within php you might want to look at HTML_QuickForm it allows custom validation rules aswell as having a set of pre-defined rules.


Comment by Loadx — May 26, 2007


is really not being unobtrusive now is it? If the classes we are going to start using start looking like


then what really is the point? The idea of being “unobtrusive” is to keep it OUT of the HTML. This is intrusive to the point of being worthless.

Comment by michael — May 26, 2007

Michael, “class=”fValidate[’required’,’=exB_Password’]” IS UNOBSTRUTIVE. It’s not the same as fValidate(’required’,’=exB_Password’) which’s a function call oO;; that class is saying: I’m a member of fValidator set. My validations are: Required and my content should be the same as the field with id exB_Password. It’s similar to have something like: class=”required exB_Password” but better since class “required” is a really common name and this way it could be incompatible with the parent application. Look, fValidator is a plug-in, not the final app. Our focus is to make a widget that just don’t mess all the legacy code that was there before it. Please, try looking into the source before saying nosense things like that oO;; the validator also provides a register method if you want to keep your html clean and define everything like object.register() at ondomready. It’s up to you to choose.

Thanks all for the other validators links. I’ll take a deep look into them and maybe update my work.

Comment by nagaozen — May 27, 2007

Fabio ,
Perhaps you don’t understand the word “unobtrusive”, or the term “Unobtrusive JavaScript”.

The word itself means inconspicuous, or not readily noticeable. The term “Unobtrusive JavaScript” is used to describe a technique that completely separates the JavaScript from the other layers of web development such as the structure and presentation layer.

With a class structure like you are using, you are yoking the JavaScript to the structure and presentation layers, and that is what my previous comment was addressing. That when you write classes that essentially look like functions, you are adding cruft in the HTML and can no longer call it “unobtrusive”. The JavaScript itself may not be in the HTML, but don’t fool yourself into believing that this is what unobtrusive scripting is about.

Maybe you should understand the technique before you go spouting nonsense about your “plug-in” being “unobtrusive”.

Comment by michael — May 28, 2007

At no point did I ever say it was a function. I said it’s structurally as bad as putting a function call in the HTML. Do you follow?

Let’s examine the similarities between the following pieces of HTML shall we?


are you going to tell me that the structure of these two snippets of HTML are that dissimilar? Other than the fact that one is a designating a class, and the other a function call, what is the structural difference?

Unobtrusive JavaScript, as a technique, is meant to replace things like:
so when you remove it from the event, and instead attach something just as intrusive to the class declaration, what is the point?

At no time did I proclaim to be an unobtrusive JS master, nor did I say the technique has been formally defined, but you yourself should look past the fact that it is not formally defined to what it is generally understood to mean, and that is right in the wikipedia entry you linked to (and I quote):

“Most notably, separation of JavaScript functionality (the “behavior layer”) from a Web page’s structure/content and presentation layers”

What part of that do you not understand? Do you really believe that:
is separating the JavaScript functionality from the page’s structure/content? Are you that obtuse?

Lastly why should you need “fValidate[blash blah blah]” at all? If you’ve already classed the FORM, you already have a hook to say that some of this FORM’s elements will have validation. So then class or ID them appropriately.

How hard is that? Why can’t you register particular IDs with the proper type of validation in the JS when you parse the form? Why can’t you say if this form element gets validated (has class fV) and its ID is “exA_Foo” it uses alpha validation? Why are you cramming it all back into the HTML? Why do I have to pass (what are essentially) variables to your JavaScript in my class names? It’s absurd.

Comment by michael — May 28, 2007


Sorry to disagree with you. If you are telling class=”fValidate[‘required’,’=exB_Password’]” is similar to onclick=”fValidate(‘required’,’=exB_Password’)” you have to agree too that “michael is a guy” is similar to “michael is a gay”. As you can see the structure isn’t enough to define one meaning.

I don’t care if you like more class=”required” over class=”fValidate[‘required’]” or think one is less intrusive than another. But the fact is that both methods are attaching behaviors to the field. Or have you ever thinked that class=”required” or class=”alpha” wasn’t standing for this purpose? If yes, sorry you are an idiot. Even in the wiki example, that class=”datefield” is saying “validate me as a date field”. The only way to separate the presentation/structure from the behavior layer at the level you want to is using the id to attach behaviors at ondomready/onload event. A way completely supported by fValidator using the method register.

I’m not obtuse, maybe you just don’t have the ideas clear in your mind. When you are solving a problem for example: a*b + a*c + a*d why can’t you write it as a*(b+c+d)? It’s the same case here, why should I write: class=”fV-required fV-equal-exB_Password fV-min-length-4″ instead of class=”fV[‘required’,’=exB_Password’,’>=4′]”? If you say that the first way is better i’ll not argue with you. I’ll just notice that you like to be verbose. In addition, if you can’t realise why it’s so important to attach a number greater than one of validations to one field, the only thing I can say is: “Poor newbie, someday you will notice why it’s necessary.” and yet, if you still thinks it’s an absurd you are helpless…

Plus, take a look in other classes and notice that classes and other properties meaning behaviors is more common than you are thinking. Here’s a small list:

class=”required validate-number” –

rel=”lightbox” –

class=”thickbox” –

and so goes on… AND as far as know, all those examples are unobtrusive.

Well to finish, I think it’s up to the developer to choose between the easy fValidator method to register things (using: class=”fValidate[validations]”) or the advanced javascript method register.

Best regards, Fabio Zendhi Nagao

Comment by nagaozen — May 29, 2007

michael is correct.
nagaozen should park in the blue spaces from now on. Your class mangling is a validation implementation detail within the markup. Bitch back and forth all you want, you are adding unnecessary junk into the raw HTML of the page. Generate the javascript somewhere else, in another file based on some other information. Turn down the suck.

Comment by Dan — May 29, 2007

You can name call all you like, but let’s not change the topic ok? We’re discussing YOUR code, not anyone else’s. The idea is to simplify the HTML, not pollute it with some verbose class structure. Yes, I believe that a well placed class can be used as a hook for JS (sometimes the circumstances makes it a necessity), and sometimes I believe people go overboard, but what you have devised is ludicrous, and it’s NOT unobtrusive. Maybe you need the word translated for you: “discreto”. And yeah, that’s my opinion, so suck it up and be a man. What’s the matter, can’t take a little criticism? Do you need a pat on the back for your hard work? Want a medal maybe? Did you expect us all to join together for a few Hallelujahs in your name? Sorry, didn’t mean to make you cry.

Comment by michael — May 29, 2007

If I may tiptoe across the flames — I think Fabio’s approach is a good step in the right direction, and Michael makes a good point about the dangers of hijacking @class.

Fabio — For the next iteration of the tool, I would suggest using true CSS classes (possibly defined microformats, where applicable) and letting the tool apply unobtrusive validation based on those class names. Two advantages to this approach (which seems to have gotten lost in the personal/emotional comments above) are: effective CSS regardless of JS support; and accessibility for Microformat-aware agents.

The current CSS spec lets you define a class as “required phone” or even “required phone seven_digit.” Your form validator could easily split the value along the spaces for multiple passes at validation, while your CSS file could provide formatting based on the conjunction of the class names.

Comment by ARWolff — May 29, 2007

Michael, you make me laugh. The reason why my works are published here is to get feedbacks from the other developers. I’m not looking for a medal or any other compliment for my hard work. Oppositely to that, I’m looking for reviews and suggestions to work more and enhance my widgets. You are so childish that talk non-sense things and still not man enough to recognize. First of all, it was you that came with a really poor comment messing functions to classes and saying “This is intrusive to the point of being worthless”. I politely posted the reasons why i named it that way and described the another more unobtrusive way to do that with the register method. After that, you came with “The term “Unobtrusive JavaScript” is used to describe a technique that completely separates the JavaScript from the other layers of web development such as the structure and presentation layer.” and “Maybe you should understand the technique before you go spouting nonsense about your “plug-in” being “unobtrusive”.” Aren’t you trying to define something here? Because looks like you think your definition of unobtrusive is better than mine. But again I tried to explain the differences and even posted a link at wikipedia where you could formalize your definition in order to help other developers to fit your rules of unobtrusiveness. Then you came messing AGAIN a class with a function and saying that I was putting together the presentation and behavior layers. Again I answered your questions (not really politely this time – in response to the obtuse) and showed that a lot of other classes in the jungle are unobtrusive and use classes or other properties to attach behaviors to their elements. After this all you came with a ultra ridiculous pathetic “We’re discussing YOUR code, not anyone else’s.” Common, we are really discussing my code or what’s unobtrusive or not?! To start, if you was really wanting to discuss my code you should say: “Fabio, I don’t like you class names cause they don’t like friendly enough for me. Shouldn’t we do this way: … … ?” And if it was a good suggestion, I’ll be glad to update the work and place a “Thanks for michael for suggestioning this behavior.” But instead of making a good suggestion you just come and say “This is intrusive to the point of being worthless.”
Common, grow up and start learning how to suggest something.

Comment by nagaozen — May 29, 2007

OMG. Someone drop the banhammer please ….
Precious internet space is being taken up by this …

Comment by Dan — May 29, 2007

Leave a comment

You must be logged in to post a comment.