aspose file tools*
The moose likes JSF and the fly likes value change events processing time in request processing life cycle Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Java » JSF
Bookmark "value change events processing time in request processing life cycle" Watch "value change events processing time in request processing life cycle" New topic
Author

value change events processing time in request processing life cycle

An Me
Greenhorn

Joined: Nov 28, 2013
Posts: 10
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
or
after Process validations phase and before Update Model Values phase
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16141
    
  21

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.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: value change events processing time in request processing life cycle