Diaries of a JSF Client Side Validation Lunatic

Day by day I’m getting closer to be a JSF Client Side Validation Lunatic. I’ve finished my beta work on the myfaces client side validation features and I’m glad everyone liked the results. I’ve brainstormed a lot on this client validation stuff in JSF and I believe I came up with the optimal solution which is as a result of a lot of experience on the topic.

JSF Client Side Validators
My initial work was a seperate validator library that enables javascript to be rendered to the client. There is a scriptgenerator component that traverses the component tree, finds the validators and encodes them. Although the results are very promising, there are some downsides. First of all, it is not in JSF nature and not compatible with the server side validations. Errors are displayed where the validator components are places not in message components. Also since the component tree is created during rendering, the approach won’t work for datatables and in case scriptgenerator component is above the validator components. I’ve donated this library to myfaces but we’ve decided to cancel the donation because of these downsides and I’ve believed there is a better approach out there(Yes, there is). So JSF Client Validators library is released in jsf-comp for now, I’m planning to get rid of the disadvantages in the next release.(0.9.2).

Shale Commons Validators
At work, the developers in my team seem to struggle with the validation stuff and we spend lots of times for input validation. My team leader Kenan Sevindik came up with the idea of integration client side validation to our project and assigned me to do the job. The library we’ve decided to use was Shale’s support for commons validator. Although I’m not a fan of using one tag to do lots of work, it seemed the best way for that time. However the thing is library itself is not usable in a real world application, I mean who fancies popups for validation, we’ve already extended message components to give them the look the customer demanded. So I’ve changed the scripts of commons-validator and the renderers of message components, also I’ve hacked shale’s validatorscript component which generates scripts by traversing the tree. It works for our project now but I’d prefer a library that works out of box. Paired with Yigit, we’ve rewritten shale validation to make it usable in an application. Also Oracle ADF which will be known as “Trinidad” from now on has client side validation, unfortunately it also uses popup but contains nice features like enabling client validation with a context-param.

MyFaces Client Side Validation
Finally, when brainstorming on figuring out a way for Apache MyFaces Client Side Validation I was looking for an idea which will be 100% compatible with the server side validation infrastructure and minimize the effort of the myfaces user to enable validation at client side. Also it should not break anything in the pages built with myfaces. So here is the big deal, each input text renderer looks for the validators of the component it renders. If there is a validator that implements IClientValidator, the renderer creates a ClientSideValidationCall object and queues it. The queue is saved temporarily at a request scope object called ClientSideValidationCallsHolder. When the form renderer takes the scene, it accesses the holder object, gets all the queued ClientSideValidationCall objects and renders them. A ClientSideValidationCall object simply has a function name and String array params which corresponds to a js validator function with parameters. Also a context param called org.apache.myfaces.ENABLE_CLIENT_SIDE_VALIDATION is used for controlling the client side validation. You can see the results of this approach at a special myfaces sandbox example project I’ve created, it’s under “Input Handling -> Validation topic” as “Client Side Validation“. Thanks to Martin Marinschek and Ernst Fastl, it is deployed at IRIAN.at.

http://www.irian.at/cagatay-validation-sandbox/home.jsf

Main Advantages;
* The key advantage of this approach is that since the renderers are extended, “there is no need to add anything” to the JSF pages, not even a single tag.
* After adding the context param, the application starts validation at client side. For security reasons, server side validation cannot be disabled and this switch only turns on/off the client side validation.
* Almost %100 compatibility with the server side, uses message components to display the errors.
* There is no tree traversal, this allows to escape performance issues and possible bugs since component tree is created during rendering(not in JSF 1.2 and Facelets).

UPDATE : 07.02.2007
This myfaces client validation project has changed a lot and it’s successor written from the beginning has joined myfaces sandbox now.

3 Responses to Diaries of a JSF Client Side Validation Lunatic

  1. Drop me a line. I’d like to ask you a question offline.

  2. JJS says:

    Hi,

    I’ve been looking for a clean implementation of client side validation for MyFaces for a few days now, and your solution looks to be the best. I tried getting the latest snapshot of MyFaces/Tomahawk/Sandbox (1.1.5) and wasn’t able to find your solution within that source tree.

    Is the code/jar available for download from another repository?

    Thanks for the help!

  3. Rajat says:

    are there updates on this ???

%d bloggers like this: