I am using a request scoped bean (manageShiftDailyDurationBean) as backing bean and a session scoped bean (manageShiftSessionData) for storing the lists on my page.
Here is the code for a select list on this page:
I noticed that when select list value is changed, the value change listener (onPayperiodDateChanged() method) is invoked before the value is set (setSelectedPayperiodDate() method). Can some one tell me why this is happening?
At the time that that listener is fired, you are provided with the backing bean's current property value and the value that it's about to be set to. And you shouldn't try and set it yourself!. That's the setter's job. I use listeners for things like detecting changes that will affect dependent UI properties.
For example, a valueChangeListener on a "States" dropdown listcontrol can be used to queue up an update to a related "Cities" dropdown options list.
Customer surveys are for companies who didn't pay proper attention to begin with.
Joined: May 23, 2006
Sorry, I don't completely understand.
You can tie a bean property to a select list so that the property is set to what ever value is selected in the select list. At the same time, you can also attach a listener to a select list that will be invoked whenever a value is selected in the select list.
In JSF life cycle, aren't setters supposed to be invoked before any events are fired? In the scenario I described, the setter is in a session scoped bean and listener method is in a request scoped bean. I don't know if it makes any difference to the order of invocation if both setter and listener method are in one bean.
As you can see from the diagram, events are fired pretty much between every stage of the JSF lifecycle, not just before firing the Action Processor.
Unfortunately, they didn't bother to indicate which events are fired between which stages. Although Phase events happen between about all of them.
The formal specs on what gets done where are in the Sun J2EE and J33 spec manuals, but they cover the full stack and I couldn't find an HTML reference internally, so I guess you'd have to download the entire PDF. Kito Mann's JSF in Action book also does a fair job of detailing this kind of stuff.
In JSF life cycle, aren't setters supposed to be invoked before any events are fired?
No, setters are invoked just about dead last. The ValueChange events are fired during that blue "Process Events" box right before the Update Model stage.
JSF is extremely protective of the data in its backing beans and lets almost everything else process first, just to make sure that things are just right. The setters are invoked as a unit - all or nothing, so if anything causes the lifecycle to bypass the Update Data phase, all properties remain unmodified. You don't get halfway into an update and break - at least if you're making proper use of validation services. And all validations are done before value change events, so this ensures that you are working with good, consistent data. Unless you break the rules and muck with them out-of-band. And I refuse to admit whether horrible things have happened to me while I learned that the hard way.
After the model has been updated, then (and only then) is it possible to fire off the action processors. First the action Listeners are invoked, in order of declaration, then the action processsor itself. Either or both of these items are optional.