wood burning stoves 2.0*
The moose likes JSF and the fly likes Session scoped bean's listener invoked before request scoped bean's set method Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Android Security Essentials Live Lessons this week in the Android forum!
JavaRanch » Java Forums » Java » JSF
Bookmark "Session scoped bean Watch "Session scoped bean New topic
Author

Session scoped bean's listener invoked before request scoped bean's set method

Murali Pen
Greenhorn

Joined: May 23, 2006
Posts: 28
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:

<h:selectOneMenu id="payperiodDates"
value="#{manageShiftSessionData.selectedPayperiodDate}"
valueChangeListener="#{manageShiftDailyDurationBean.onPayperiodDateChanged}">
<f:selectItems value="#{manageShiftSessionData.payperiodDatesItemList}" />
</h:selectOneMenu>

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?


Murali
SCJP,SCBCD,SCWCD
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 15960
    
  19

Because it's supposed to.

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.
Murali Pen
Greenhorn

Joined: May 23, 2006
Posts: 28
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.

Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 15960
    
  19

http://java.sun.com/j2ee/1.4/docs/tutorial/doc/JSFIntro10.html

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.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Session scoped bean's listener invoked before request scoped bean's set method
 
Similar Threads
selected value through select items
doubt in value change event
h:selectOneMenu values customization
validation and data flow
Specific method for bean JSF!