You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by "Max Muermann (JIRA)" <de...@myfaces.apache.org> on 2005/11/16 21:50:28 UTC
[jira] Created: (MYFACES-833) HtmlFormRendererBase saves form state before components have been rendered - breaks auto id generation
HtmlFormRendererBase saves form state before components have been rendered - breaks auto id generation
------------------------------------------------------------------------------------------------------
Key: MYFACES-833
URL: http://issues.apache.org/jira/browse/MYFACES-833
Project: MyFaces
Type: Bug
Components: Implementation
Versions: 1.1.0
Environment: Sun JDK 1.5
Windows XP
Facelets 1.0d/1.0e
Tomcat 5.x
Reporter: Max Muermann
In HtmlFormRendererBase, the following code is executed in the encodeBegin() method:
//write state marker at the beginning of the form
ViewHandler viewHandler = facesContext.getApplication().getViewHandler();
viewHandler.writeState(facesContext);
This causes problems (especially when using facelets), as some components first call getClientId() - which causes a new id for the component to be generated by the ViewRoot - in their own encodeBegin() method.
If this is the case, as the form encodeBegin() is called before any of its child components are rendered, those components that do not yet have an id assigned save their state with a null id. When the view state is restored in the next request, these ids will be regenerated, starting with _id0. However, if there are other components in the page that also require autogenerated ids, some ids will be duplicated and the "problem" components will receive different ids to when they were first rendered.
Attached is a patch to HtmlFormRendererBase which moves the state saving operation of the form to the encodeEnd() method, where all child components will have been rendered and therefore will have called getClientId() at least once.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (MYFACES-833) HtmlFormRendererBase saves form state before components have been rendered - breaks auto id generation
Posted by "Max Muermann (JIRA)" <de...@myfaces.apache.org>.
[ http://issues.apache.org/jira/browse/MYFACES-833?page=comments#action_12357816 ]
Max Muermann commented on MYFACES-833:
--------------------------------------
Ah, that's where the problem comes from - looks like it's a problem in Facelet's ViewHandler implementation, which saves out the state at this point. Will take it up with the Facelets guys again.
> HtmlFormRendererBase saves form state before components have been rendered - breaks auto id generation
> ------------------------------------------------------------------------------------------------------
>
> Key: MYFACES-833
> URL: http://issues.apache.org/jira/browse/MYFACES-833
> Project: MyFaces
> Type: Bug
> Components: Implementation
> Versions: 1.1.0
> Environment: Sun JDK 1.5
> Windows XP
> Facelets 1.0d/1.0e
> Tomcat 5.x
> Reporter: Max Muermann
> Attachments: HtmlFormRendererBase.java.diff
>
> In HtmlFormRendererBase, the following code is executed in the encodeBegin() method:
> //write state marker at the beginning of the form
> ViewHandler viewHandler = facesContext.getApplication().getViewHandler();
> viewHandler.writeState(facesContext);
> This causes problems (especially when using facelets), as some components first call getClientId() - which causes a new id for the component to be generated by the ViewRoot - in their own encodeBegin() method.
> If this is the case, as the form encodeBegin() is called before any of its child components are rendered, those components that do not yet have an id assigned save their state with a null id. When the view state is restored in the next request, these ids will be regenerated, starting with _id0. However, if there are other components in the page that also require autogenerated ids, some ids will be duplicated and the "problem" components will receive different ids to when they were first rendered.
> Attached is a patch to HtmlFormRendererBase which moves the state saving operation of the form to the encodeEnd() method, where all child components will have been rendered and therefore will have called getClientId() at least once.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (MYFACES-833) HtmlFormRendererBase saves form state before components have been rendered - breaks auto id generation
Posted by "Simon Kitching (JIRA)" <de...@myfaces.apache.org>.
[ http://issues.apache.org/jira/browse/MYFACES-833?page=comments#action_12357815 ]
Simon Kitching commented on MYFACES-833:
----------------------------------------
Are you aware that the ViewHandler.writeState method simply writes a special marker string into the response stream, not the actual state?
Once the entire page has been processed, code goes back and finds those special state markers and replaces them with the actual state.
That's why the comment is there on that line of code.
See JspViewHandlerImpl.java method writeState, and ViewTag.java method doAfterBody.
> HtmlFormRendererBase saves form state before components have been rendered - breaks auto id generation
> ------------------------------------------------------------------------------------------------------
>
> Key: MYFACES-833
> URL: http://issues.apache.org/jira/browse/MYFACES-833
> Project: MyFaces
> Type: Bug
> Components: Implementation
> Versions: 1.1.0
> Environment: Sun JDK 1.5
> Windows XP
> Facelets 1.0d/1.0e
> Tomcat 5.x
> Reporter: Max Muermann
> Attachments: HtmlFormRendererBase.java.diff
>
> In HtmlFormRendererBase, the following code is executed in the encodeBegin() method:
> //write state marker at the beginning of the form
> ViewHandler viewHandler = facesContext.getApplication().getViewHandler();
> viewHandler.writeState(facesContext);
> This causes problems (especially when using facelets), as some components first call getClientId() - which causes a new id for the component to be generated by the ViewRoot - in their own encodeBegin() method.
> If this is the case, as the form encodeBegin() is called before any of its child components are rendered, those components that do not yet have an id assigned save their state with a null id. When the view state is restored in the next request, these ids will be regenerated, starting with _id0. However, if there are other components in the page that also require autogenerated ids, some ids will be duplicated and the "problem" components will receive different ids to when they were first rendered.
> Attached is a patch to HtmlFormRendererBase which moves the state saving operation of the form to the encodeEnd() method, where all child components will have been rendered and therefore will have called getClientId() at least once.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (MYFACES-833) HtmlFormRendererBase saves form state before components have been rendered - breaks auto id generation
Posted by "Adam Winer (JIRA)" <de...@myfaces.apache.org>.
[ http://issues.apache.org/jira/browse/MYFACES-833?page=comments#action_12357828 ]
Adam Winer commented on MYFACES-833:
------------------------------------
No, it's not a problem with Facelets. It's a *difference* between JSPs and Facelets, and MyFaces should not be assuming that its JspViewHandler is the one true way of implementing a ViewHandler.
The bug is legit; MyFaces should use encodeEnd(), not encodeBegin().
Also, see section 4.1.4 of the JSF 1.1 spec, which requires the use of encodeEnd().
> HtmlFormRendererBase saves form state before components have been rendered - breaks auto id generation
> ------------------------------------------------------------------------------------------------------
>
> Key: MYFACES-833
> URL: http://issues.apache.org/jira/browse/MYFACES-833
> Project: MyFaces
> Type: Bug
> Components: Implementation
> Versions: 1.1.0
> Environment: Sun JDK 1.5
> Windows XP
> Facelets 1.0d/1.0e
> Tomcat 5.x
> Reporter: Max Muermann
> Attachments: HtmlFormRendererBase.java.diff
>
> In HtmlFormRendererBase, the following code is executed in the encodeBegin() method:
> //write state marker at the beginning of the form
> ViewHandler viewHandler = facesContext.getApplication().getViewHandler();
> viewHandler.writeState(facesContext);
> This causes problems (especially when using facelets), as some components first call getClientId() - which causes a new id for the component to be generated by the ViewRoot - in their own encodeBegin() method.
> If this is the case, as the form encodeBegin() is called before any of its child components are rendered, those components that do not yet have an id assigned save their state with a null id. When the view state is restored in the next request, these ids will be regenerated, starting with _id0. However, if there are other components in the page that also require autogenerated ids, some ids will be duplicated and the "problem" components will receive different ids to when they were first rendered.
> Attached is a patch to HtmlFormRendererBase which moves the state saving operation of the form to the encodeEnd() method, where all child components will have been rendered and therefore will have called getClientId() at least once.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (MYFACES-833) HtmlFormRendererBase saves form state before components have been rendered - breaks auto id generation
Posted by "Howard Abrams (JIRA)" <de...@myfaces.apache.org>.
[ http://issues.apache.org/jira/browse/MYFACES-833?page=all ]
Howard Abrams updated MYFACES-833:
----------------------------------
Fix Version: 1.1.3
> HtmlFormRendererBase saves form state before components have been rendered - breaks auto id generation
> ------------------------------------------------------------------------------------------------------
>
> Key: MYFACES-833
> URL: http://issues.apache.org/jira/browse/MYFACES-833
> Project: MyFaces
> Type: Bug
> Components: Implementation
> Versions: 1.1.0
> Environment: Sun JDK 1.5
> Windows XP
> Facelets 1.0d/1.0e
> Tomcat 5.x
> Reporter: Max Muermann
> Fix For: 1.1.3
> Attachments: HtmlFormRendererBase.java.diff
>
> In HtmlFormRendererBase, the following code is executed in the encodeBegin() method:
> //write state marker at the beginning of the form
> ViewHandler viewHandler = facesContext.getApplication().getViewHandler();
> viewHandler.writeState(facesContext);
> This causes problems (especially when using facelets), as some components first call getClientId() - which causes a new id for the component to be generated by the ViewRoot - in their own encodeBegin() method.
> If this is the case, as the form encodeBegin() is called before any of its child components are rendered, those components that do not yet have an id assigned save their state with a null id. When the view state is restored in the next request, these ids will be regenerated, starting with _id0. However, if there are other components in the page that also require autogenerated ids, some ids will be duplicated and the "problem" components will receive different ids to when they were first rendered.
> Attached is a patch to HtmlFormRendererBase which moves the state saving operation of the form to the encodeEnd() method, where all child components will have been rendered and therefore will have called getClientId() at least once.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Closed: (MYFACES-833) HtmlFormRendererBase saves form state
before components have been rendered - breaks auto id generation
Posted by "Martin Marinschek (JIRA)" <de...@myfaces.apache.org>.
[ http://issues.apache.org/jira/browse/MYFACES-833?page=all ]
Martin Marinschek closed MYFACES-833:
-------------------------------------
Resolution: Fixed
Assign To: Martin Marinschek
Fixed by moving the state encoding back to where it belongs
> HtmlFormRendererBase saves form state before components have been rendered - breaks auto id generation
> ------------------------------------------------------------------------------------------------------
>
> Key: MYFACES-833
> URL: http://issues.apache.org/jira/browse/MYFACES-833
> Project: MyFaces
> Type: Bug
> Components: Implementation
> Versions: 1.1.0
> Environment: Sun JDK 1.5
> Windows XP
> Facelets 1.0d/1.0e
> Tomcat 5.x
> Reporter: Max Muermann
> Assignee: Martin Marinschek
> Fix For: Nightly
> Attachments: HtmlFormRendererBase.java.diff
>
> In HtmlFormRendererBase, the following code is executed in the encodeBegin() method:
> //write state marker at the beginning of the form
> ViewHandler viewHandler = facesContext.getApplication().getViewHandler();
> viewHandler.writeState(facesContext);
> This causes problems (especially when using facelets), as some components first call getClientId() - which causes a new id for the component to be generated by the ViewRoot - in their own encodeBegin() method.
> If this is the case, as the form encodeBegin() is called before any of its child components are rendered, those components that do not yet have an id assigned save their state with a null id. When the view state is restored in the next request, these ids will be regenerated, starting with _id0. However, if there are other components in the page that also require autogenerated ids, some ids will be duplicated and the "problem" components will receive different ids to when they were first rendered.
> Attached is a patch to HtmlFormRendererBase which moves the state saving operation of the form to the encodeEnd() method, where all child components will have been rendered and therefore will have called getClientId() at least once.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (MYFACES-833) HtmlFormRendererBase saves form state before components have been rendered - breaks auto id generation
Posted by "Max Muermann (JIRA)" <de...@myfaces.apache.org>.
[ http://issues.apache.org/jira/browse/MYFACES-833?page=all ]
Max Muermann updated MYFACES-833:
---------------------------------
Attachment: HtmlFormRendererBase.java.diff
> HtmlFormRendererBase saves form state before components have been rendered - breaks auto id generation
> ------------------------------------------------------------------------------------------------------
>
> Key: MYFACES-833
> URL: http://issues.apache.org/jira/browse/MYFACES-833
> Project: MyFaces
> Type: Bug
> Components: Implementation
> Versions: 1.1.0
> Environment: Sun JDK 1.5
> Windows XP
> Facelets 1.0d/1.0e
> Tomcat 5.x
> Reporter: Max Muermann
> Attachments: HtmlFormRendererBase.java.diff
>
> In HtmlFormRendererBase, the following code is executed in the encodeBegin() method:
> //write state marker at the beginning of the form
> ViewHandler viewHandler = facesContext.getApplication().getViewHandler();
> viewHandler.writeState(facesContext);
> This causes problems (especially when using facelets), as some components first call getClientId() - which causes a new id for the component to be generated by the ViewRoot - in their own encodeBegin() method.
> If this is the case, as the form encodeBegin() is called before any of its child components are rendered, those components that do not yet have an id assigned save their state with a null id. When the view state is restored in the next request, these ids will be regenerated, starting with _id0. However, if there are other components in the page that also require autogenerated ids, some ids will be duplicated and the "problem" components will receive different ids to when they were first rendered.
> Attached is a patch to HtmlFormRendererBase which moves the state saving operation of the form to the encodeEnd() method, where all child components will have been rendered and therefore will have called getClientId() at least once.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira