On 6/5/06,
Cagatay Civici <[EMAIL PROTECTED]> wrote:
Hi,
I want to introduce the idea that I've come up with when I was working on the integration of the client side validation support for myFaces. Martin and I agreed this is the optimal solution for the problem for now.
The aim is to minimize the effort of the myfaces user and do not break anything in the jsf pages already created. In order to do this,I've added a few lines of code to the inputtextrenderer and extended the form renderer.
Each inputtextrenderer checks for the validators like required attribute and queues a ClientValidatorCall object for each of them. This ClientValidatorCall object consists of the js function name, and parameters. The queue is hold using a request scope ClientValidatosCalls bean. This bean has a set of ClientValidatorCall objects.
After the form renderer does it's job, it accessed the ClientValidatorCalls bean and encodes the js function calls by iterating the queue.
Main advantages are the following;
"* Users do not need to change anything in their pages."
* A context param called ENABLE_CLIENT_VALIDATION acts a switch to turn on/off the client validation.
* By default validation messages are displayed using the t:message and t:messages components.
* If desired popups can also be used to display the error messages.
* Validation can run onsubmit, onblur, onkeypress and etc. All depends on the user's wish.
I've implemented this idea, to make the required attribute's validation on client. It worked like a charm, and the best thing is I've not changed anything on the page.
To clarify the idea, I could say it looks like the relationship between facesmessages and h:messages component. As you know h:messages accesses the facesmessages added and renders them. Similiar to formrenderer and validationcalls.
I'd be glad to hear your thoughts on this, If it is all agreed, I'll start providing the patches.
Regards,
Cagatay Civici
www.jroller.com/page/cagataycivici
--
Grant Smith
