aspose file tools*
The moose likes JSF and the fly likes valueChangeListener behavior Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » JSF
Bookmark "valueChangeListener behavior" Watch "valueChangeListener behavior" New topic
Author

valueChangeListener behavior

Naveen Sampra
Ranch Hand

Joined: Jun 11, 2003
Posts: 70
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.

Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16145
    
  21

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.


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: valueChangeListener behavior