I began today with a long-term goal of getting the core page of the application written. This is the page that will allow users to create, edit, view, and manage prayer requests.
Before half an hour passed, I knew I needed to study RichFaces. We hope to use a lot of rich components in the application, enabling the user to make changes large or small without refreshing the entire page, and to facilitate easy searches and selections. so I looked up the RedHat team’s RichFaces Live Demo, and spent the better part of the morning “geeking out” over all the exciting components they offer. It was so much fun that it is the Website of the Day!
Then it was time for a simple test; I decided I would add rich validation to the account creation page, telling the user on screen if his or her field entries were too short or too long, saving the trouble of waiting through an entire refresh to find out.
This test was successfully completed approximately six hours later. Lack of RichFaces knowledge led me on a merry chase for the correct functionality. With Mr. Chandler’s help, I made several useful discoveries.
First, in order to implement a4j and RichFaces, certain filters and context parameters are required in the web.xml, and they can be order-sensitive.
Second, in order to work properly, RichFaces must be allowed to access a file in the server path.
Our filter was intercepting this call. We fixed it by making the filtered path one step more specific, excluding the one called by RichFaces.
Finally, I discovered that a functional RichFaces validation on a simple field can be accomplished using the following simple process.
In our xhtml page, we first added the following line inside our input box tags:
<a4j:support event=”onkeyup” reRender=”passwordMsg” requestDelay=”1000″ />
This instructs a4j to wait 1000 milliseconds after the first keystroke in the input box is released, and then to reRender the component with the id ‘passwordMsg’. The requestDelay is included to prevent the server from processing requests generated by every keystroke.
Second, we added the following code after the closing tag for the input box.
<a4j:outputPanel id=”passwordMsg”>
<h:message for=”password” showDetail=”true” style=”color:red;” />
</a4j:outputPanel>
This is the panel reRendered by the support component. The h:message simply begins a normal validation process.
In conclusion, I am happy to say that today was tidy, encapsulated by the accomplishment of a single goal.
Today’s Note for Dense Summer Interns: The solution to your RichFaces problem is probably just one webpage away. Don’t keep experimenting with complicated solutions when you could be exploring more rich components!
Filed under: Jobber's Log | Tagged: JSF, RichFaces, Validation
