You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by bu...@apache.org on 2005/07/19 06:43:33 UTC
DO NOT REPLY [Bug 35764] -
[shale] Clay View-Handler doesn't work correctly with client side state saving.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=35764>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=35764
------- Additional Comments From gvanmatre@comcast.net 2005-07-19 06:43 -------
Client side state saving for the Clay full view might be tricky to support
between faces implementations. It looks like both myfaces and the RI follow
the same sequences.
ViewHandler.renderView
UIForm.encodeEnd
viewHandler.writeState - writes a marker token to the response
stream if client side state is on
ViewTag.doAfterBody
makes a clone of the response writer
applies the clone to the faces context
statemanager.saveSerializedView returning the state in a
Statemanager.SerializedView if client side state
Looks in the response writer for a marker token
statemanager.writeWriteState()
creates a ResponseStateManger, writes the serialized state to
the body as an hidden field.
The ClayViewHandler simulates the actions of the ViewTag in the renderView
method. This is where I think it would get tricky. The token maker placed in
the response writer is not standardized. The token is not the same between
the RI and myfaces so the logic to find the form marker would need to be
implementation specific.
I'm not sure how we could make client side state support implementation
neutral?
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org