This only happens if you set the render option on the fireAjaxTransaction to be a limited set of components. This is because isStateWritten is set to be true by the form renderer (encodeBegin or encodeEnd) so you need to have gone through that.
Should I not be able to just set the components to be re-rendered to be a sub-set of those on the form though?
Presumably there is an amount of overhead associated with re-rendering everything when I know that only some things will have changed.
Steven
From: Steven Oglesby [mailto:Steven.Oglesby_at_coexis.com]
Sent: 05 October 2007 10:45
To: users_at_jsf-extensions.dev.java.net
Subject: Dynafaces and Facelets problem
Hello,
I am using Dynafaces 0.1-rc-4 and Facelets 1.1.12. I have a page that has an input that uses fireAjaxTransaction inorder that validation can happen on the server. This works fine. However, when I then press a button to confirm the changes things go wrong. This button results in the page being re-displayed.
The problem is that the page that is displayed after pressing the confirm button has lots of bogus html elements in it. I have debugged and found that this is because the transient components are not being stripped from the view when the Ajax call is made. They therefore build up in the view and all get written out when you next do a standard refresh.
What happens on a normal page refresh is that Facelets rebuilds the component tree and adds in lots of transient components that relate to plain html markup. Then at the end it strips these out (FaceletViewHandler asks the statewriter isStateWritten. If so you call state manager saveSerializedView which strips out the transient components).
During the Ajax call the statewriter isStateWritten call returns false and so you never end up stripping out the transient components.
I cannot see an issue in the issues list relating to this. Not sure if it is due to the version of Facelets that I am using?
Has anyone else seen this and know how to fix it?
Steven