• 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
  • Tim Cooke
  • paul wheaton
  • Jeanne Boyarsky
  • Ron McLeod
Sheriffs:
  • Paul Clapham
  • Liutauras Vilda
  • Devaka Cooray
Saloon Keepers:
  • Tim Holloway
  • Roland Mueller
Bartenders:

valueChangeListener behavior

 
Ranch Hand
Posts: 70
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Tim and others,

I'm at a loss at following valueChangeListener behavior. I could not find this behavior in the documentation. If anyone wants they can use the code below and create simple facelet and managed bean to test. I'm using JSF 1.2.

I have a simple JSF page with 2 input componenets.




MBean class has following action methods:


Below are 2 issues I found:

1) valueChangeListener method gets fired during validation phase.


This is an issue since I need to invoke business logic and update bean values in valueChangeListener method.
I want the new values to get rendered on page. However my values gets overwritten in the later phases. Should'nt action/listener methods get invoked in invoke application phase ? How do I update bean values on the server side based on drop down selection and redisplay after post back?


2. valueChangeListener method gets fired although no value was changed
Enter a value in inputText and clicking save fires valueChangeListener and then saveSPConfig action method. However I did NOT change drop down value.

From the logs below I see why this happens, but this is incorrect behavior. User did not select a new value from drop down.


valueChangeListener is a common feature. I'm pretty sure there's a standard pattern out there to fix above behavior.


Overall I think the JSF model is quite complex. The detailed life cycle phases make the model very robust but at the same time a very big learning curve. What would be nice is to have a good design pattern book for JSF.

 
Saloon Keeper
Posts: 28469
210
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
Stop right there.

You should not change bean properties or invoke business logic in a valueChangeListener.

JSF is predicated on a simple go/no-go method of data updating. Only if all controls on the form pass validation should the bean be updated and they will then be updated by the JSF controller automatically at the same time. The action processor is then fired to invoke the business logic.

When you attempt to use a valueChangeListener for update and business purposes, you invalidate this paradigm. The proper use for valueChangeListeners is for things like cascaded SelectItem lists, where you are updating the UI. For example, if you have a "Select State" control and a "Select City" control, you might use a valueChangeListener to initiate a chane to the City SelectItem collection.

A big problem with JSF is that way too many people try and make it more complicated than it needs to be. JSF does a pretty good job of handling the bulk of the everyday grunt work using simple POJO properties and methods. A JSF backing bean that's laced with a complex assortment of non-model javax.faces package classes and low-level methods is usually an indicator that the author didn't understand the basic JSF technology.
 
Happiness is not a goal ... it's a by-product of a life well lived - Eleanor Roosevelt. Tiny ad:
New web page for Paul's Rocket Mass Heaters movies
https://coderanch.com/t/785239/web-page-Paul-Rocket-Mass
reply
    Bookmark Topic Watch Topic
  • New Topic