JSF and immediate.

Question

Hi,
I have a form in JSF where I add a record to a database. When the user clicks
add, a form appers with the input fields and two buttons add and cancel.
The add button calls the action handler and adds the record to the database
while the cancel redirects back to the main page by using a navigation rule.
My problem is that if the user fills the input fields and clicks cancel then
the next time he tries to add another record the old unsubmitted values are
there. I suppose the values are saved in the component even with if the
cancel button has the immediate attribute.
myHandler is a managedBean with session scope and newRecord is
the object I want to save in the database.
I have misundestood something in JSF propably so any help is very
appreciated.
Thanks
Petros
<%@ taglib uri="http://java.sun.com/jsf/html" prefix="h" %>
<%@ taglib uri="http://java.sun.com/jsf/core" prefix="f" %>
<f:subview id="addRecord">
<h:form>
    <h:panelGrid columns="2">
         <f:facet name="header">
             <h:panelGroup>
                  <h:outputText value="#{labels.title}"/>
               </h:panelGroup>
          </f:facet>
          <h:outputText value="#{labels.description}:"/>
          <h:panelGroup>
              <h:inputText id="desc" value="#{myHandler.newRecord.description}" required="true" maxlength="40"/>
              <h:message for="desc" styleClass="errorMessage" />
          </h:panelGroup>
          <h:commandButton value="#{labels.add}" action="#{myHandler.add}"/>
          <h:commandButton value="#{labels.cancel}" immediate="true" action="cancel"/>
     </h:panelGrid>
</h:form>
</f:subview>

Answer 1

Ok, figured out my problem.
Well, I knew the problem; I now have a SOLUTION.
The problem: User enters data, gets a validation error, wants to
discard submitted values and start over. (Cancel / undo / revert.)
Canonical solution:
<h:commandLink value="Undo" action="undo" immediate="true"/>along w/a navigation rule in faces-config.xml:
<navigation-rule>
  <from-view-id>/detail.jsp</from-view-id>
  <navigation-case>
    <from-outcome>undo</from-outcome>
    <to-view-id>/detail.jsp</to-view-id> <!-- Note: same view from
                                         which we came -->
  </navigation-case>
</navigation-rule>How this works is:
phase "Restore view": old view is dredged up from somewhere (session?
request data?).
phase "Apply Request Values": incoming values are decoded and copied
into components' submittedValue properties (which already have the
same old junky data in them anyway, but never mind).
At the end of this phase, the "immediate" commandLink has caused, in
the course of being decoded, an action event to be queued, and it is
now processed. The action "undo" (static string) is "invoked" (no
joke, I've seen the code), resulting in a return status of... (wait
for it)... "undo"! (The invocation is a no-op. In spite of my
clowning around, it's not a bad architecture.)
Also, since an action was invoked (phase "Invoke Application"), all
other (intervening) phases are skipped and we now go straight to phase
"Render Response", but first....
We look up the action result "undo" in the navigation rules for this
page, and (by virtue of looking up a non-null string) get a hit. (At
least, I THINK we "get a hit" regardless -- even if there's no
matching navigation-case.)
We now instantiate a brand-new view (even if it's the same page we're
going back to), discarding all our carefully-saved submittedValues.
This is exactly the effect we want: skip phase "Update Model" and
discard that submitted junk the user no longer wants.
NOW we proceed w/phase "Render Response", and everything's copacetic.
The old junk doesn't show up, and we rebuild the page from the model
(which probably hits the database).
So much for the "trivial"/canonical case.
Didn't work for me.
The effect I noticed was that the submittedValues kept coming back.
Why?
After much debugging w/the source release and Eclipse (yay!), I
discovered that my use of the "binding" attribute on a component
changed everything.
<h:dataTable id="surveyTable" var="question"
    binding="#{surveyMgr.surveyTable}">I keep forgetting this simple truth: value bindings are
two-way. They insert data into your model (1) and pull it back
out (2). Two (2), count 'em, TWO, flows.
Tying the component into the model is fine, if you need access to it
(e.g., to determine what the current row is, for some nefarious/hacky
purpose).
However, after the new, empty view has been instantiated and we begin
to populate the component w/components, I discovered the following
functionality in the JSF source code:
When attempting to instantiate a new component, check to see if the
"binding" attribute was used. If so, evaluate the value
binding, using the UIComponent returned by it instead of creating
a new one.
Youch! Now my old dataTable, complete with its junk submittedValues
comes back into my new, clean view! Even though my bean is request
scoped. (The bean got initialized at the beginning of the request,
before the new view was created, while the old view was still "good".)
So, the real solution:
(Should be fairly obvious.)
<h:commandLink value="Undo" action="#{surveyMgr.undo}" immediate="true"/>
public class SurveyMgr {
  public String undo() {
    // One of two possibilities here.
    return "undo";
}Two possibilities:
(1) Carefully clean out the bean (in particular, the bound UIComponent
properties, storing null in their place). A surgical approach
might be good here, if there's data you want to keep in the bean,
for some reason. Drawback: if some poor developer introduces a
new value binding at some point in the future and doesn't clean it
out during the "undo" operation, they'll be faced w/the same
mystery. At best, they'll have to stop and search for the page
you carefully put into your company's internal wiki (which you
did, right? right?).
(2) Blast the entire bean, as outlined in a previous post in this
thread (createValueBinding().setValue(null)). This seems to work
for me, even though it's a request-scoped bean and we're in the
middle of the request processing. I initialize my bean lazily
with non-Faces hidden parameters (Yet Another Sad Hack), so your
mileage may vary.
Problem solved. For real. (Until I discover that this doesn't work,
either.)
John.