No ideas here

HTML forms validation is always a pain. You must process the validation both server and client-side. The server-side part is obviously a problem of your server framework, but the client side is a problem that must be solved by JavaScript. I always used some custom scripts, for every project the same thing that was rewritten every time. Almost same code was used in different projects. So I told myself that I should do something about it, and decided to write a small JavaScript library to support client side forms validation. My goal was to have a JavaScript framework that will allow me to check the form with minimal use of coding. I wanted something like configuration driven validation. Another goal was to provide a consistent error reporting, so the user is always informed in a standard way, and the user will always know what is the problem. The error reporting also consists of translatable error messages. Yet another goal was to provide a consistent set of validation rules that can be applied on a wide range of the controls, and further extended.

Defining the validation

To define validation, I decided to use css classes to set the constraints. That means that you don’t need to call any code at all, but just include some javascript files, add some css classes to html tags, and the library will take care about it itself. Of course, you would be able to call all the things by coding, but this was not the point. The full automation is the biggest deal here.

Validation rules are defined as css classes. So some general information about its structure: validation rules always start with “val_”. For example rule for required field is “val_required”, so you will write:

<input type="text" class="val_required your_class">

Some rules can have parameters. These parameters are passed to the rule code automatically. For example if you want to define a rule for minimal length of 2 letters, you will use this code:

<input type="text" class="val_minlen-2">

Some rules can be applied to multiple types of components, but most not. The work on my todo list is an automatic checking of the validity of the control type.

Validation rules

There are included several validation rules that match the most of the needs. Of course, you can always add your own validation rules.The list of rules follows.

• required - presence of text or presence of
• minlen - minimal length of text or minimal number of selected items in select html element
• maxlen - maximal length of text or maximal number of selected items in select html element
• minvalue - minimal value
• maxvalue - maximal value
• int - value must be a number
• float - value must be a floating point number
• email - valid email address

Reporting errors

Error reporting is the final step towards the user. Displaying an alert is not enough anymore. Much more convenient towards the user would be to add the error message behind (on the right side of) the form field, and remove the error when it is not necessary.

The error is reported with the name of the field that is taken from the associated label. If no label can be found, the generic error text is used.

As it was said, it is possible to use localisation. Currently, the only supported localisation are generic English (so one for England, Australia, South Africa, and the US) and Czech. This part obviously needs a lot of attention in the future. If you want to change the localisation, you must explicitly state it as a class in your form. The class name is “val_lang-cz”.

Simple usage

So now it is a time to show some simple usage of the validation. Just a simple usage follows. Its purpose is to illustrate how to use it. The following input text has to contain at least 3 and at most 10 characters.

<input type=”text” name=”username” class=”val_required val_minlen-3 val_maxlen-10″ />

Future directions

The future directions would be to make sure that the validation works in any browser. Further adding more validators, adding an immediate error reporting after the control looses the focus, some more work at internationalisation is also needed. Further some more work at checking various types of controls is needed. Documentation needs to be updated, but to be honest, there is never enough documentation. Maybe I will add some more advanced AJAX validation of more complex situation that need communication with the server.

So that’s all. Hope you will enjoy it. I promise, since I will use it from today, I will update the code regularly, patch bugs, and release new features. This version is just a preview of what it might contain, so comments here, bugs to martin at kronos-software.eu.

DOWNLOAD

Documentation

I have a big problem with end key on Mac. In every application it behaves differently. Why is the situation like that? I don’t know. Some applications scroll to the end of document, some text editors move the caret to the very last position of the editor, some text editors move the caret to the end of line. Who should know what the current application does? But this is only a part of the problem.

The Apple Human Interface Guidelines document mentions that the end key should scroll to the end of document. This sounds ok as long as you don’t mention text editors. In such a case I am not in favour of this at all. I would like to change it to move to the end of line. Reason? How many times do you want to scroll to the end of file, and how many times do you want to move the caret to the end of line? My rate would be something like 0:100. Yes, no need to scroll somewhere to the end of the document at all! If I need to do something at the end of the document, I would use Cmd+Page Down to move the caret there.

This end key behaviour is very hostile to all people who work with text a lot (read developers). And it’s not only the End key, but also Home key, Page Up, Page Down. We need to move around very quick, and we don’t want to touch mouse when we need to change something somewhere! This idea of just scrolling is nice as long as the control doesn’t contain any selection or caret. In such a situation, it’s unusable.

Another example are lists. You can think as an example Adium’s contact list. I have many contacts there. 4 screens in my case. When I would like to write some my friend, I need to either type his name, or I can scroll around with Page Down/Up, and then select him by mouse, and then start writing. I would like to keep my hands on the keyboard, and not to lift them to the mouse. Again moving with the selection would be so much better.

So what to say at the end? This time Mac is the looser, because sadly Windows is better in this case.