Originally posted by Bagwan Mehrat:
I'm new to JSF, but I've been trying it out, and have problems with JSF remembering and restoring component values that I don't want it to.
I am writing a JSP page that allows users to edit contacts. So if a user wants to edit contact #1, he goes to the page "/edit.jsf?id=1", or id=2, and so on.
When a page request is made, the request scope backing bean's constructor loads the contact values it needs. This arrangement usually works fine.
That edit.jsf (actually edit.jsp) page has <h:inputText> tags for editing the contact information. Some of these are mandatory, so are set to required=true.
The problem begins innocently does something like blank a required inputText and submits it with the <h:commandButton> provided in the form. JSF detects that this is invalid, and redisplays edit.jsf with the submitted data, and an <h:message> error message. So far, so good.
But then, if the user decides that that particular contact, call that one #1, really didn't need to be edited anyway, and goes on to edit another contact, say #2, without correcting and resubmitting the form, then the page for contact #2 ("/edit.jsf?id=2") will populate the form with the information from the previously submitted contact #1.
It makes sense that JSF "remembers" the submitted values when redisplaying edit.jsf after the validation error, but isn't the JSF framework smart enough to figure out that it shouldn't do that for subsequent requests? Is there a way to get around this problem by somehow clearing something in FacesContext, or kicking the JSF page out of whatever lifecycle stage it's stuck in?
I'm using JBoss 4.0.3, which bundles Tomcat and MyFaces.
- Varun
Wally Hartshorn
Originally posted by M Litherland:
In your submit method you could just say attrib=""; Or perhaps I'm not understanding your problem?
Originally posted by Bagwan Mehrat:
I am writing a JSP page that allows users to edit contacts. So if a user wants to edit contact #1, he goes to the page "/edit.jsf?id=1", or id=2, and so on.
Originally posted by Bagwan Mehrat:
To answer my own question, to work around this problem what I had to do was allow the user navigate back to the previous list page with a commandButton or commandLink. If the user navigates back using a plain outputLink or even using the browser Back button, JSF gets confused.
Originally posted by Alexander Jesse:
I would say here is your problem...
JSF is not made to listen to such URL-parameters.
This is not a workaround, but the only correct way to do it...