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.
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.
An IDE is no substitute for an Intelligent Developer.