Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 2.2 Sprint 12
    • Fix Version/s: None
    • Component/s: Lifecycle
    • Labels:
      None
    • Environment:

      Any

      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?

        Issue Links

          Activity

          Hide
          tedgoddard added a comment -

          (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.

          Show
          tedgoddard added a comment - (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.
          Hide
          Ed Burns added a comment -

          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?

          Show
          Ed Burns added a comment - 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?
          Hide
          Ed Burns added a comment -

          Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.

          Show
          Ed Burns added a comment - Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.
          Hide
          Manfred Riem added a comment -

          Setting priority to Major. Verify if we are already doing the right thing.

          Show
          Manfred Riem added a comment - Setting priority to Major. Verify if we are already doing the right thing.

            People

            • Assignee:
              Unassigned
              Reporter:
              dmsinotte
            • Votes:
              2 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

              • Created:
                Updated: