From my understanding about value change events,
Value change events are fired in the Apply Request Values phase and processed in the Process Validations phase.
But as I search the internet,most of the images are confusing me about the actual processing times of value change events.My doubt is..
When are the value change events actually processed(without immediate set to true)...
during Process Validations phase
after Process validations phase and before Update Model Values phase
Value changes do not get handled when immediate=true, because the definition of immediate=true is that data does not get sent to the server, therefore there is no incoming value to see changes on.
Value change events also do not fire unless JSF actually detects that the incoming value is unequal to the current bean value of that property. It quite literally does what its name says.
Value change listeners are often abused. As a general rule, they should NOT be used to set backing bean properties (since JSF does that automatically), and they should definitely avoid doing any processing that has side-effects or will take a significant amount of time.
My most common use for value change listeners is when I have cascading selections. I set up my property "get" methods to initialize the selection lists (and pre-selected value) of dependent selections if the selection list has been set to null. That allows me to handle 2 cases: the first request selection and subsequent requests when the parent selection has changed (meaning that a new sub-selection list is needed to correspond to the new parent selection). I cache these values so that the initialization only has to be done when null. The valuechange listener will null the selection list and dependent selection value when it is fired, since it knows that a changed parent selection requires new children.
Customer surveys are for companies who didn't pay proper attention to begin with.
subject: value change events processing time in request processing life cycle