Fundamental JSF Lifecyle Problem

Question

This is more concise description of a prior refresh problem. The goal is to change detail information when a menu selection is made on the form.
When the menu is changed the form is submitted and the value-change event handler makes calls to the managed session bean to change the details to reflect the new selection.
To faclitate this "refresh" operation the menu is marked as "immediate" and the event handler calls renderResponse on the context to skip the model update phase of the requestion.
This strategy works perfectly when the details are displayed with read-only components � including setting the read-only property on an input textbox. If read-write components are used to display details, changing the menu has no effect on the display! My code still executes. The data models definitely do change when the menu selection changes.
I am stumped on this one.

Answer 1

Hi again!
I aked Craig about this and he reminded me of a trick he had to use in AppModel to handle this issue - my previous response over-simplified things.
Yes, it's JSF lifecycle related... in particular with how input components deal with this lifecycle with immediate set to true. Here's his email message that might help explain.... we are working on articulating this in a tutorial with some kind of "best practice" recommendation...
============
Let's look inside, say, a Text Field component to see what actually happens in each phase:
* Reconstitute View -- The previous state of the component (as of when it was rendered)
is restored.
* Apply Request Values -- The decode() method is called, which extracts the appropriate
request parameter (as a string), and calls setSubmittedValue() to save the input in its raw form.
* Process Validations -- (See note [1]) convert the submittedValue into the appropriate data
type, then call any validators. If conversion was successful and no validation errors were
encountered, call setValue() to save the converted value, and fire a value change event
if appropriate.
* Update Model Values -- If there is a value binding expression on the value property,
use it to push the converted and validated value into the model tier. Set submittedValue
to null since we don't need it any more.
* Invoke Application -- Nothing special.
* Render Response -- (See note [2]) If submittedValue is not null, redisplay that. Otherwise, call getValue(),
do any necessary conversion, and render that.
[1] If immediate="true", the processing that normally happens in Process Validations is moved up to happen in Apply Request Values instead.
[2] This is the behavior that causes the symptom reported by the forum poster. The reason JSF behaves this way is that users expect, after a validation error, that whatever you typed will be redisplayed so you can fix it -- even if it's semantically invalid. For example, assume you have a Text Field that is bound to an int field (so there's an integer converter in the picture). If you type in "1a3", the converter will fail, and you expect to see an error message with "1a3" redisplayed. It is the special test for submitted values in Render Response that actually meets this requirement.
In terms of lifecycle, then, we need to figure out how to describe the following best practice:
* IF you set immediate=true on an input field,
* AND you intend to perform some processing
in a value change listener, then redisplay
the current page,
* AND you modify the value property of this
component, or any other input component
on the page in your event listener code,
* THEN you must call setSubmittedValue(null)
on that input component before returning from
the value change listener.
You don't have problems like this in the non-immediate scenario, because setSubmittedValue(null) is called for you in Update Model Values.
==========
So to help with this, we added the erase method on the FacesBean class to clear all the submitted values on the page- see the jsfcl doc:
http://developers.sun.com/prodtech/javatools/jscreator/reference/apis/index.html
... and you can see this "in action" in the AppModel example on the Single.java page bean... search for the "erase" method (we needed to use it for AppModel because the dropdown is an input component and has auto-submit=true which sets immediate):
http://developers.sun.com/prodtech/javatools/jscreator/reference/codesamples/sampleapps.html
Hope that helps....
v