4:50 p.m.
In the case of server-side state saving, implementation of
ResponseStateManager saves a new state for an every request,even for a
same viewId as previous was, and generates a new value for
"javax.faces.ViewState" hidden field. That feature allows JSF to restore
proper view state then user returns to previous page by browser "back"
button and submit some form from that page again.
But that behaviour is incorrect for AJAX requests because in this case
browser does not save page in history ( Even if "back" button support
for AJAX will be implemented, it could be done by special 'iframe'
object only, and does not save page in history anyway ), and old values
is only going to garbage. As a result, small view states cache ( which
default size is 16 ) could be refilled by values from AJAX requests
soon, and browser "back" button support will be broken.
Patch to fix that issue have been attached to
https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=549
6:18 p.m.
+1
We have discussed this as an important distinction for ICEfaces
applications as well.
Ted.
On 29-Apr-09, at 3:50 PM, Alexandr Smirnov wrote:
In the case of server-side state saving, implementation of
ResponseStateManager saves a new state for an every request,even for a
same viewId as previous was, and generates a new value for
"javax.faces.ViewState" hidden field. That feature allows JSF to
restore
proper view state then user returns to previous page by browser "back"
button and submit some form from that page again.
But that behaviour is incorrect for AJAX requests because in this case
browser does not save page in history ( Even if "back" button support
for AJAX will be implemented, it could be done by special 'iframe'
object only, and does not save page in history anyway ), and old
values
is only going to garbage. As a result, small view states cache ( which
default size is 16 ) could be refilled by values from AJAX requests
soon, and browser "back" button support will be broken.
Patch to fix that issue have been attached to
https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=549
8:02 p.m.
Alexandr's fix is now checked into the impl. Roger is looking at the spec.
Jim
On 4/29/09 4:18 PM, Ted Goddard wrote:
+1
We have discussed this as an important distinction for ICEfaces
applications as well.
Ted.
On 29-Apr-09, at 3:50 PM, Alexandr Smirnov wrote:
> In the case of server-side state saving, implementation of
> ResponseStateManager saves a new state for an every request,even for a
> same viewId as previous was, and generates a new value for
> "javax.faces.ViewState" hidden field. That feature allows JSF to restore
> proper view state then user returns to previous page by browser "back"
> button and submit some form from that page again.
> But that behaviour is incorrect for AJAX requests because in this case
> browser does not save page in history ( Even if "back" button support
> for AJAX will be implemented, it could be done by special 'iframe'
> object only, and does not save page in history anyway ), and old values
> is only going to garbage. As a result, small view states cache ( which
> default size is 16 ) could be refilled by values from AJAX requests
> soon, and browser "back" button support will be broken.
> Patch to fix that issue have been attached to
> https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=549
>
10:42 a.m.
Hey Alexandr,
Thanks for catching this. I'm adding the following to the
javax.faces.render.ResponseStateManager.writeState method:
* <p>If the state saving method for this application is {@link
* javax.faces.application.StateManager#STATE_SAVING_METHOD_SERVER},
* and the current request is an <code>Ajax</code> request
* (@link javax.faces.context.PartialViewContext.isAjaxRequest} returns
* <code>true</code>), use the current view state identifier if it is
* available (do not generate a new identifier).</p>
-roger
Alexandr Smirnov wrote:
In the case of server-side state saving, implementation of
ResponseStateManager saves a new state for an every request,even for a
same viewId as previous was, and generates a new value for
"javax.faces.ViewState" hidden field. That feature allows JSF to restore
proper view state then user returns to previous page by browser "back"
button and submit some form from that page again.
But that behaviour is incorrect for AJAX requests because in this case
browser does not save page in history ( Even if "back" button support
for AJAX will be implemented, it could be done by special 'iframe'
object only, and does not save page in history anyway ), and old values
is only going to garbage. As a result, small view states cache ( which
default size is 16 ) could be refilled by values from AJAX requests
soon, and browser "back" button support will be broken.
Patch to fix that issue have been attached to
https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=549
5484
days inactive
5485
days old
jsr-314-open-mirror@lists.jboss.org
3 comments
4 participants
participants (4)
-
Alexandr Smirnov -
Jim Driscoll -
Roger Kitain -
Ted Goddard