javaserverfaces-spec-public
  1. javaserverfaces-spec-public
  2. JAVASERVERFACES_SPEC_PUBLIC-153

Add property to UIData to enable transient state saving within request

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: 1.2
    • Fix Version/s: 2.1
    • Component/s: Components/Renderers
    • Labels:
      None
    • Environment:

      Operating System: All
      Platform: All

    • Issuezilla Id:
      153
    • Status Whiteboard:
      Hide

      EGTop5 effort_hard cat2 javadoc size_large importance_large

      Show
      EGTop5 effort_hard cat2 javadoc size_large importance_large

      Description

      I've run into this problem a few times and a number of other people have as
      well. This issue brings into question when to save the state of the components
      inside of a UIData and when not to. Based on this discussion
      (http://mail-archives.apache.org/mod_mbox/myfaces-dev/200603.mbox/%3c9eb65db00603020129n23c0e486k@mail.gmail.com%3e)
      it seems to be generally accepted that UIData should following the same rules of
      any other component when saving the state of its children regardless of
      validation state or if it's nested. It is also believed that this is a spec
      issue because of verbiage in UIDate.encodeBegin() JavaDocs.

      Here is a simple test case that illustrates the problem:
      -----------test.jsp------------
      <%@ taglib uri="http://java.sun.com/jsf/html" prefix="h" %>
      <%@ taglib uri="http://java.sun.com/jsf/core" prefix="f"%>
      <f:view>
      <h:form>
      <h:dataTable value="#

      {test.values}

      " var="value">
      <h:column>
      <h:message for="item"/>
      <h:inputText id="item" required="true" /><br/>
      </h:column>
      </h:dataTable>
      <h:inputText id="item2" /><br/>
      <br/>
      <h:commandButton value="Submit Me"/>
      </h:form>
      </f:view>

      ------------------Test.java------------------
      import java.util.ArrayList;
      import java.util.List;

      public class Test {
      public List getValues()

      { List values = new ArrayList(4); values.add(null); values.add(null); values.add(null); values.add(null); return values; }

      }

      Basically, if you populate all of the inputText boxes and press "Submit Me" then
      the top 4 forget their value but the bottom one does not. If you only populate
      a subset of the top 4 boxes (invoking an invalid state for the table) then all
      the fields are remembered. However, once all fields are populated the
      components in the table forget their state again when submitted. All the while
      the bottom inputText, which resides outside the dataTable, remembers its state
      the whole time.

      Similar problems have been brought forward in issue 140 and issue 73 (in the
      jsf-ri project). However, those issues and their patches have mostly revolved
      around quarks in UIData forgetting state in various cases where data was not
      validated. Those two issues have not been fixed because of a backwards
      compatibility issue with 1.1, they break the "Repeater" demo/component. The
      main difference between this issue and the existing 2 is this issue covers a
      broader scope. This issue asserts that UIData state should be saved following
      the same rules as a normal component without all of the complicated rules that
      currently exist in UIData surrounding validation failing and nested UIData
      components.

      That said a fix to this issue would most likely break the same demo (maybe more)
      the other two issues break so those implications will need to be taken into
      account. I am unsure of the implications of breaking backwards compatibility
      with 1.1 demos, however, I personally believe that UIData's current state saving
      model is a source of confusion and frustration to many JSF developers and a fix
      would provide more benefit than maintaining the backwards compatibility of the
      current state saving model. I believe fixing this issue would be nice addition
      to 1.2.

      Mike

      1. changebundle.txt
        43 kB
        Ed Burns
      2. changebundle.txt
        140 kB
        Ed Burns
      3. changebundle.txt
        58 kB
        Ed Burns
      4. FixUIData.txt
        5 kB
        lu4242
      5. fixUIDataComponentStateMojarraWithMarkInitialStateFix-1.patch
        35 kB
        lu4242
      6. fixUIDataComponentStateMojarraWithMarkInitialStateFix-2.patch
        47 kB
        lu4242
      7. fixUIDataComponentStateMojarraWithoutMarkInitialStateFix-1.patch
        37 kB
        lu4242
      8. i153.patch
        36 kB
        Ed Burns
      9. i153.patch
        35 kB
        Ed Burns
      10. message.txt
        5 kB
        Ed Burns
      11. myfaces-uidata-component-state-test.zip
        34 kB
        lu4242
      12. UIDataComponentStateMojarraJUnitTest.patch
        3 kB
        lu4242

        Issue Links

          Activity

          Hide
          Ed Burns added a comment -

          Committed revision 8700.
          Editorial suggestions by Andy Schwartz

          Show
          Ed Burns added a comment - Committed revision 8700. Editorial suggestions by Andy Schwartz
          Hide
          Ed Burns added a comment -

          Created an attachment (id=336)
          Too many iterations to count. This one has much simpler spec language thanks to Andy Schwartz

          Show
          Ed Burns added a comment - Created an attachment (id=336) Too many iterations to count. This one has much simpler spec language thanks to Andy Schwartz
          Hide
          kenpaulsen added a comment -

          r=kenpaulsen

          Show
          kenpaulsen added a comment - r=kenpaulsen
          Hide
          Ed Burns added a comment -

          Committed revision 8705.

          Show
          Ed Burns added a comment - Committed revision 8705.
          Hide
          Manfred Riem added a comment -

          Closing resolved issue out

          Show
          Manfred Riem added a comment - Closing resolved issue out

            People

            • Assignee:
              Ed Burns
              Reporter:
              youngm
            • Votes:
              1 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: