Thanks Leonardo. I'll get an issue opened tomorrow morning and attach a
sample war to recreate.
Leonardo Uribe wrote:
2009/10/21 Michael Concini <[email protected]
<mailto:[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]> <mailto:[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
