2009/10/21 Michael Concini <[email protected]> > Leonardo, > > I disabled partial state saving, and everything works as expected. I had > also previously tried using the same snippet in a JSP and it worked ok there > as well. So the problem is definitely only occurring with partial state > saving enabled. > > I'm not sure I follow how the binding attribute would come into play in > this scenario. The value change listener is being engaged ok. In fact, the > problem seems to be occurring well before that listener is engaged. The > component's restoreState method is never actually being called, so when the > value change listener is getting called during validation, its being passed > the original value from the page, not the updated value that should have > been restored from the previous state. > -Mike > > I remember that a delegate pattern is used when binding attribute is used. See org.apache.myfaces.taglib.core.ValueChangeListenerTag and org.apache.myfaces.view.facelets.tag.jsf.core.ValueChangeListenerHandler . The reason about why do that comes from jsf 1.2. If you file an issue and attach the example I'll take a look at this one.
regards Leonardo Uribe > Leonardo Uribe wrote: > >> Hi >> >> 2009/10/20 Michael Concini <[email protected] <mailto:[email protected] >> >> >> >> >> All, >> >> I've run into what appears to be a bug in the new state >> saving/restoring code for facelets. >> I've got a simple xhtml page with a one field form and a value >> change listener attached. The listener simply outputs the old >> value and the new value to SystemOut. On every postback, its >> showing the old value as what was originally set by the 'value' >> attribute and not the value from the previous request as would be >> expected. >> <h:form id="form1"> >> <h:commandButton value="Press here" id="testListeners" /> >> <h:inputText id="testValueChangeListener" value="some text"> >> <f:valueChangeListener >> binding="#{coreTagsBean.testValueChangeListener}" >> type="listener.TestValueChangeListener" /> >> </h:inputText> >> </h:form> >> >> I stepped through the code in the debugger, and when we get into >> DefaultFaceletsStateManagementStrategy.restoreView(), the states >> are always coming up null in the return object array returned form >> the HtmlResponseStateManager from this code snippet (lines 160-161 >> in my view) >> >> state = (Object[]) manager.getState (context, viewId); >> states = (Map<String, Object>) state[1]; >> >> Since states is null, when we execute restoreStateFromMap(), we >> don't ever execute the restoreState() method on the component >> since we have not recovered the state data. >> >> I've stepped through the code for state saving, and it looks to me >> as though the state data for the input text field is being saved >> properly, but I'm not very familiar with how the state >> saving/restoring code works. I'd be happy to continue doing the >> debugging if someone could point me in the right direction, but I >> would appreciate any help from those in the community who are more >> familiar with the state management code. >> >> >> The first part works as expected (state=null). For partial state saving, >> the component tree is built on every request. If nothing changes, no state >> is saved for the component. In jsf 2.0, there was some changes related to >> the behavior of binding attribute, so maybe it is related to this one. It >> could be good to test is without partial state saving, to see how it should >> behave. >> >> regards, >> >> Leonardo Uribe >> >> Thanks, >> Mike >> >> >> >
