[ http://issues.apache.org/jira/browse/MYFACES-102?page=comments#action_60617 ] Heath Borders-Wing commented on MYFACES-102: --------------------------------------------
I'd say this is more of a feature than a bug. I don't think that all UIInputs should save their value when it is read from the value binding all the way through to when it is updated. If you don't want ValueChangeEvents, make the bean session-scoped, or put code in your ValueChangeListener to check for a non-null value. > ValueChangeListener Invoked in every post back > ---------------------------------------------- > > Key: MYFACES-102 > URL: http://issues.apache.org/jira/browse/MYFACES-102 > Project: MyFaces > Type: Bug > Reporter: dani kenan > > When the value property is bound to a request scoped managed bean field, e.g.: > <h:selectOneMenu > id="typeName" > value="#{typeListPage.typeName}" > valueChangeListener="#{typeListPage.onChangeTypeName}" > > > <f:selectItems value="#{typeNameSelectItems}" /> > <h:selectOneMenu> > The event is fired in every post to the server, even if no change occurred. > The event is fired during the validation phase. This is because the framework > compares the posted value against the value in the bean, not the saved value > of the selectOneMenu ui control. > In order to determine if a value change occured, the value posted in the > request (which is never null) is compared agains the current value of the > bean property (due to the binding #{typeListPage.typeName}). This propety > which is not yet initialized (the bean is in request scope bean - thus > typeName is always null before the update model phase), and the value change > event fires. > The problem is simple: change event fires when no event occures. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira
