Julien Martin wrote:
Hello,
I have several components in my jsf page each having a valuechangelistener
attribute and each attribute having a corresponding methods in my backing
bean.
public void attributeAChanged(ValueChangeEvent evt){
public void attributeBChanged(ValueChangeEvent evt){
in the jsp:
valueChangeListener="#{PopulateListsBean.attributeAChanged}"
valueChangeListener="#{PopulateListsBean.attributeBChanged}"
Does anyone know why the first declared method is always called even if
attributeB is changed??
I was not able to find anywhere in the spec anything related to that.
Can anyone help?
This sure looks like a bug to me; I can't see anything wrong with your
code. Multiple valueChangeListener methods should be supported AFAIK. I
presume you are checking which methods are called by logging output in
each one, or using breakpoints?
By the way, in a later email you give this code:
> ***********************
> public void contractCodeChanged(ValueChangeEvent evt){
> log.info("contractCodeChanged");
> this.contractCode = (String) evt.getNewValue();
> }
Updating the model from a value-changed-event is probably not a good
idea. These callbacks get executed at the end of the validation phase,
and are run even if validation failures have occurred on other
components. Therefore if a validation failure has occurred then the
value-change-listener method is called but the model is never updated
from other components.
Note also that you have:
<h:selectOneMenu
value="#{PopulateListsBean.contractCode}"
...
so during the update phase the contractCode field will be updated by the
component, ie your contractCodeChanged method's change to that property
will be very brief. Of course in this case you're just assigning the
final value a bit early (for some reason) so in this case a value X is
being overwritten with value X.
And finally, if there *is* a validation failure then the selectOneMenu
component will re-render itself using the value cached in the model
rather than fetching from the model.
Regards,
Simon
