This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
The JSF standard Request Life cycles consist of phases which works perfectly fine in case of a simple flow.
But in case of where I have several validations/controls with logic in my UI page, I have to play around a lot to get things done, which seems too buggy at times.
Just to implement a "reset" functionality in page containing a required input field (with a required attribute ="true"), I have to play around a lot to get things done. Infact I noticed couple of JSF dons at java.sun suggesting me to open a new page everytime the user click the "reset" button to get this implemented, which sounds pretty odd.
Now most pages in my application contains validation/ font end logic etc. and looking at the app now I wonder if I am really using JSF standard life cycle or playing with it
For your date example, you want to suppress validation when you select a radio button. You can do that by setting selectOneRadio's immediate attribute to true.
The JSF lifecycle is very flexible. You can skip parts of it or all of it as you deem necessary. You can also selectively opt out of validation with immediate events. Of course, like any other power tool, you have to be careful.
Intelligent design of JSF components, such as a date picker, will almost always require some script. I try to only hit the server when I have a finished value to send to the server. If I'm trying to affect a change in the UI, I prefer scripts.