Diaries of a JSF Client Side Validation Lunatic
June 14, 2006 3 Comments
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
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.
* 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.