• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

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

 
Greenhorn
Posts: 28
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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?
 
Saloon Keeper
Posts: 27752
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Murali Pen
Greenhorn
Posts: 28
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 27752
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic