Dynafaces and Facelets problem

[Steven Oglesby]

Some parts of this message have been removed. Learn more about Nabble's security policy.

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

[Steven Oglesby]

Some parts of this message have been removed. Learn more about Nabble's security policy.

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@...]
Sent: 05 October 2007 10:45
To: users@...
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

[Steven Oglesby]

Some parts of this message have been removed. Learn more about Nabble's security policy.

In fact this comes down to the fact that I have my own StateManager. I managed to get it installed so that it wraps the DeferredStateManager provided by DynaFaces. AsyncResponse.getViewState only calls stuff on the state manager if it is the DynaFaces one. This meant the required methods to clean up the transients were never called.

 

The order that state managers are installed appears to come down to the names of the jars that hold the faces-config files. It sorts them into alphabetical order. Perhaps I am missing something, but this seems rather dodgy (especially since the JSF spec says it should come down to how the class loaders return getResources).

 

 

From: Steven Oglesby [mailto:Steven.Oglesby@...]
Sent: 05 October 2007 12:26
To: users@...
Subject: RE: Dynafaces and Facelets problem

 

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@...]
Sent: 05 October 2007 10:45
To: users@...
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