<< Back to previous view

[JAVASERVERFACES_SPEC_PUBLIC-1093] The id attribute of javax.faces.ViewState is not unique Created: 01/May/12  Updated: 08/Nov/13

Status: Open
Project: javaserverfaces-spec-public
Component/s: Lifecycle
Affects Version/s: 2.2 Sprint 12
Fix Version/s: None

Type: Bug Priority: Major
Reporter: dmsinotte Assignee: Unassigned
Resolution: Unresolved Votes: 2
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Any


File Attachments: Zip Archive viewstate.zip    
Issue Links:
Related
is related to JAVASERVERFACES_SPEC_PUBLIC-790 javax.faces.ViewState + PPR does not ... Open
Tags:
Participants: dmsinotte, Ed Burns and tedgoddard

 Description   

As per the work done for this spec change, http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-220, the id of each hidden ViewState element is supposed to be unique on the page. This should hold true for multiple forms in a single view as well as multiple views on the page (e.g. portlets). The documentation in ResponseStateManager indicates that this should be done by setting the id to be:

namingContainerId:javax.faces.ViewState:counterUniqueToView

I have attached a test case which has two forms on it. The resulting ViewState elements both have identical ids:

ViewState for form1: j_id1:javax.faces.ViewState:0
ViewState for form2: j_id1:javax.faces.ViewState:0

The counter is not incremented and the id of the form (which should be the naming container in this case) is not used.

Also, I noticed that the method for getting the ViewState id is com.sun.faces.util.Util.getViewStateId(FacesContext fc). For those of us working on extending the framework who might need access to the information in their own renderers, will there be a way to get at the information in a more public way?



 Comments   
Comment by tedgoddard [ 03/May/12 04:25 PM ]

(First of all, javax.faces.ViewState should not be modified for Ajax updates using server-side state-saving, but this simple approach does not appear to be the current direction.)

We are a bit unclear on how the current implementation is intended to work, but expect that something like the following is necessary:

When the request is submitted, call getElementsByName('javax.faces.ViewState') and store the list of IDs for all with equal value to that of the javax.faces.ViewState in the submitting form. In the case of future JSP inclusion or current Portlets, there will be javax.faces.ViewState fields not associated with the current view. They will have different values and are not included in the list.

When the partial response is generated, it may contain rendered hidden inputs with name javax.faces.ViewState and unique IDs, but also contains the special case <update id="javax.faces.ViewState"><![CDATA[...]]></update>. The previously stored list of IDs are now all updated to use the new value. Any javax.faces.ViewState hidden fields that have been modified by the page update itself (potentially now having different IDs) have the correct value anyway because they were just updated.

Comment by Ed Burns [ 03/May/12 06:35 PM ]

TG> (First of all, javax.faces.ViewState should not be modified for Ajax
TG> updates using server-side state-saving, but this simple approach
TG> does not appear to be the current direction.)

Can you please elaborate more on what you mean by this? The issue
doesn't mention anything about Ajax specifically. Is this a separate
concern you are raising, Ted?

TG> We are a bit unclear on how the current implementation is intended
TG> to work, but expect that something like the following is necessary:

TG> When the request is submitted, call
TG> getElementsByName('javax.faces.ViewState') and store the list of IDs
TG> for all with equal value to that of the javax.faces.ViewState in the
TG> submitting form. In the case of future JSP inclusion or current
TG> Portlets, there will be javax.faces.ViewState fields not associated
TG> with the current view. They will have different values and are not
TG> included in the list.

TG> When the partial response is generated, it may contain rendered
TG> hidden inputs with name javax.faces.ViewState and unique IDs, but
TG> also contains the special case <update
TG> id="javax.faces.ViewState"><![CDATA[...]]></update>. The previously
TG> stored list of IDs are now all updated to use the new value. Any
TG> javax.faces.ViewState hidden fields that have been modified by the
TG> page update itself (potentially now having different IDs) have the
TG> correct value anyway because they were just updated.

These two comments are better suited to JAVASERVERFACES_SPEC_PUBLIC-790,
so I'll copy them there. Ted, can you please take a look at 790 and see
if you agree that your comments pertain more to that issue than this
one?

Generated at Sat Apr 19 02:35:28 UTC 2014 using JIRA 4.0.2#472.