I have a backing bean which does a DB query to return a list of beans - with an accessor of getBeans(). Each bean is displayed as a row in a h:dataTable, with certain fields being directly editable as h:inputText's - specifically the get/setRuleText() member.
I added a cancel buton (non-immediate) which simply nulls out the underlying member variable for getBeans(), returning null to stay on the same page, and resulting in the list getting regenerated next time getBeans() gets called.
This was working fine, but things went wrong once I added a custom validator. I could no longer cancel if there was an invalid entry. So I figured I could just add the immediate flag and everything would be hunky dory.
With the immediate flag present, the cancel button would work, and trigger my action, but the getRules() method would not get called again for the rest of that lifecycle, and though I wouldn't get validation errors, the data in the view objects was not being refreshed - just showing the pre-cancel data.
However I noticed that if I left and came back to the page, it would then show the correct data. Thus we come to my tip - instead of returning null from the cancel action to stay on the same page, return a string which triggers an explicit navigation rule, and this will cause the view objects to refresh and call the getters as needed.
Not sure if this is a bug or expected behavior - please feel free to enlight this JSF newbie either way =)