Java Notes From My Desktop

Tags - Categories : All | Articles | Book Reviews | CSS | Java | Javaranch | Javascript | News | Opengl | Opinions | Personal | php

The Problem

I have a form where the top quarter is Employee Information. The bottom 3 quarters are issue details about the employee. When the form is first loaded all the employee information is blank. There is a field for Employee ID and a Lookup button. When the ID is typed in and the Lookup button pressed, the Empoyee Information fields are populated accordingly. Everything worked great, until I added validation.

There are only 2 fields in the bottom part of my form that need to be validated. Issue Type and Summary. Both of these fields are required for every issue. The problem, if you haven't guessed already, is that when I would click on the Lookup button, the page would validate and I would recieve errors about the 2 required fields. Enter the immediate attribute.

I added immediate="true" to my Lookup button. Then I redeployed the application for testing. Clicking the Lookup button now submitted the page, however, none of my employee information was filled in. Looking at my log files I noticed that my ObjectNotFound exception was being thrown because the Employee ID field was blank. After some investigation it seems to be that since the immediate="true" cause the action to be executed during the "Apply Request Values" phase, the Employee ID is not even being put in the request. Now, I am not an expert on JSF's phases but saying that an attribute does something and then coming in behind and saying that it's only in a specific phase makes for strange implementation.

Interestingly enough, all the examples that demonstrate using the immediate attribute are with Cancel buttons. So to correct all the documentation out there on the immediate attribute...

Only use immedate="true" if you need to cancel the current form without causing validation.

The Solution

Well, there isn't a solution. This is just how it is. But I did a workaround. Instead of doing automatic validation on those 2 fields, when my Save button is clicked and my saveIssue method is called, the first thing I do is check those 2 fields for validity. If either fails I simply added a message to the FacesContext and then return my failure string so the issue page is displayed with the appropriate error messages.

If anyone knows a better solution for this problem I would love to hear it. I would also like to know if there is anything in the next JSF release that is going to change the behavior of the immediate attribute. It seems like it would have been better to just copy ASP.NET on this one and have an attribute called causesValidation. And then this would simply skip the validation phase.


immediate=true prevents values to be populated on model (backin bean) but they shouldn't clear values from UI elements.
(You should still be able to get them, but referencing UI controls directly -- not backing model bean).
Think of it as a _not_so_easy_ way of doing actions while still having values deffered from commiting to backing model. (and afaik asp.net doesn't have something like MVC even implemented, then you really shouldn't compare those two approches)

Cheers, a.
The use case you describe is why there is an "immediate" property on UIInput components (like the Employee ID field) as well as on UICommand components (like the lookup button). If you set immediate="true" on the input field as well as on the button, then the data in that input field will be available in the button's action handler, and can be used for looking up the requested employee and redisplaying the same page.
Craig, thanks for the tip. I tried that and it still didn't pull the employeeId from the inputText. I am using MyFaces. I can't imagine that affecting this but who knows.
Hi. This may be a little late to help but I've recently come up against this problem myself. I assumed that when the "immediate" attribute was set to true on an input field and also on a command component, that the backing bean model would be updated, but without going through validation of other input fields. This was not the case. The values of the immediate="true" field is still accessible, but it must be retrieved programmatically via a UIComponent object.
This seems "logical" if you look at the implementation. One cannot move values to the backing bean without validation as one of the "contracts" of the model states that it never receives invalid values (because an earlier JSF phase has validated the response)... Setting immediate effectively "removes" the contract for the fields marked but not for the entire backing bean.
try the jsf-comp.jar
This MyFaces Wiki entry has information that may help.
Here's my understanding of "immediate": When any form is submitted, it goes through all the lifecycle phases of JSF. Setting immediate as true skips the validation phase and all the JSF specific phases (update model values{this would mean not populating your backing bean from the component} and invoke application) and move to the render response phase. if you dont want to validatte some fields on a page on click of a button but still have some action associated with it, my suggestion would be to keep these fields in separate forms.
I found this article helpful for getting around validation. http://www.developertutorials.com
When using immediate="true" on a commandButton as in your situation, I would use actionListener attribute and in it's method call processUpdate.
public void actionListenerMethod(ActionEvent e){
e.getComponent().processUpdates();
}
Parameterizable validators are a tricky thing; they need to be represented in various configuration files and on top of that need to be stateful. Read on to find out how you can use validator tags with custom attributes. ...

Read more...


Add a comment

Title
Body
HTML : b, i, blockquote, br, p, pre, a href="", ul, ol, li
Math Quiz 10 + 6 = (Helps stop blog spam)
Name
E-mail address
Website
Remember me Yes  No 

E-mail addresses are not publicly displayed, so please only leave your e-mail address if you would like to be notified when new comments are added to this blog entry (you can opt-out later).

TrackBack to http://radio.javaranch.com/gthought/addTrackBack.action?entry=1104874993000