javaserverfaces
  1. javaserverfaces
  2. JAVASERVERFACES-1721

Components inside ui:repeat can not be reset to null

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Trivial Trivial
    • Resolution: Won't Fix
    • Affects Version/s: 2.0.2
    • Fix Version/s: None
    • Component/s: facelets
    • Labels:
      None
    • Environment:

      Operating System: All
      Platform: All

    • Issuezilla Id:
      1,721
    • Status Whiteboard:
      Hide

      size_medium importance_medium includes_patch

      Show
      size_medium importance_medium includes_patch

      Description

      We are experiencing some strange behaviour using ui:repeat: it does not reset
      any object values to null but instead keeps the initial state. We tried
      debugging a lot but unfortunately it is not easy to trace where this goes
      wrong. In the UIRepeat class the value seems to be set correctly first but then
      gets lost again somewhere in the
      private void setIndex(FacesContext ctx, int index)
      Method. Probably a wrong client state gets restored after the
      PROCESS_VALIDATIONS Phase. This might be a side effect of the internal
      representation of the UIRepeat class that creates an additional UIComponent
      which is also visible using visitTree and seems to mix-up in the restore State.

      The reproducer is very simple: just a ui:repeat with nested Integer Converter
      for instance (the Converter must just return null for an empty String):

      <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
      "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

      <html xmlns="http://www.w3.org/1999/xhtml" lang="en"
      xmlns:h="http://java.sun.com/jsf/html"
      xmlns:f="http://java.sun.com/jsf/core"
      xmlns:ui="http://java.sun.com/jsf/facelets">
      <head>
      <title>UIRepeat</title>
      </head>
      <body>
      <h:form id="theTestForm">
      <ui:repeat value="#

      {testBean.testList}

      " var="testHolder">
      <h:inputText value="#

      {testHolder.theInt}

      " id="integer"/>
      <br/>
      </ui:repeat>
      <h:commandButton value="apply" action="#

      {testBean.apply}

      "/>
      </h:form>
      </body>
      </html>

      The Backing bean returning some test-ListItem:

      @ManagedBean(name = "testBean")
      @SessionScoped
      public class FileTestBean {
      private final Logger logger = Logger.getLogger(this.getClass());
      List<TestHolder> testList = new ArrayList<TestHolder>();

      public String addHolderLevel()

      { testList.add(new TestHolder()); return null; }

      public List<TestHolder> getTestList() {
      if (testList.size() < 2)

      { testList.add(new TestHolder()); testList.add(new TestHolder()); }

      return testList;
      }

      public void setTestList(List<TestHolder> testList)

      { this.testList = testList; }

      public String apply()

      { return null; }

      }

      The TestHolder:

      public class TestHolder {
      private Integer theInt;

      public Integer getTheInt()

      { return theInt; }

      public void setTheInt(Integer theInt)

      { this.theInt = theInt; }

      }

      Once the value is set it cannot be reset to null. this occurs for 1-n items in
      the UIRepeat list, for more than 2 items the visitTree() output we introduced
      before and after every phase becomes really bad/wrong too: it seem to output
      getValue only from the last Component for every component until
      process_validations phase.
      The debug output of the example looks like:

      Pattern: getValue()-getSubmittedValue()-getClientId()

      beforePhase:PROCESS_VALIDATIONS 3
      ComponentTreeVisitor: 2--theTestForm:j_idt3:0:integer << wrong getValue
      (should be 1)
      ComponentTreeVisitor: 2--theTestForm:j_idt3:1:integer
      ComponentTreeVisitor: 2-null-theTestForm:j_idt3:2:integer << “ghost
      component�

      {IntegerConverter} - getAsObject will return null if true: true{IntegerConverter}

      - getAsObject will return null if true: true

      {PfidLifecycleValidator} - afterPhase:PROCESS_VALIDATIONS 3{PfidLifecycleValidator}

      - ComponentTreeVisitor: 1-null-
      theTestForm:j_idt3:0:integer << null value not applied

      {PfidLifecycleValidator} - ComponentTreeVisitor: 2-null-
      theTestForm:j_idt3:1:integer{PfidLifecycleValidator}

      - ComponentTreeVisitor: 2-null-
      theTestForm:j_idt3:2:integer

        Activity

        Hide
        bitec added a comment -

        Guys, who are you calling? )) No one from JSF team will do anything, most of all they even don't see this issue as it is closed. Just create your component (as I did in many cases) and fix it )) But the best is simply avoid JSF and use other UI frameworks - you will save much more time.

        Show
        bitec added a comment - Guys, who are you calling? )) No one from JSF team will do anything, most of all they even don't see this issue as it is closed. Just create your component (as I did in many cases) and fix it )) But the best is simply avoid JSF and use other UI frameworks - you will save much more time.
        Hide
        Darious3 added a comment -

        @bitec I think the JSF team works very hard and creates an excellent product. It's simply impossible to pick up each and every issue if there are literally hundreds of them.

        I don't think avoiding JSF is the answer at all, all other frameworks have issues just as well. Ever looked at the GWT tracker? It ain't pretty I tell you.

        Nevertheless, ui:repeat in Mojarra is a troublesome component. Did anyone try the MyFaces version? I'm not saying MyFaces is overall better, but in the case of ui:repeat it looks like to have less problems.

        A blog article about this issue was posted here: http://blog.oio.de/2013/01/29/problem-with-uirepeat-and-null-values-in-jsf-2-x

        Show
        Darious3 added a comment - @bitec I think the JSF team works very hard and creates an excellent product. It's simply impossible to pick up each and every issue if there are literally hundreds of them. I don't think avoiding JSF is the answer at all, all other frameworks have issues just as well. Ever looked at the GWT tracker? It ain't pretty I tell you. Nevertheless, ui:repeat in Mojarra is a troublesome component. Did anyone try the MyFaces version? I'm not saying MyFaces is overall better, but in the case of ui:repeat it looks like to have less problems. A blog article about this issue was posted here: http://blog.oio.de/2013/01/29/problem-with-uirepeat-and-null-values-in-jsf-2-x
        Hide
        phallama added a comment -

        richfaces component lib (a4j:repeat) I can recommend. It seems to be stable and works well for all my ui:repeat purposes. http://docs.jboss.org/richfaces/latest_4_X/Component_Reference/en-US/html/chap-Component_Reference-Tables_and_grids.html#sect-Component_Reference-Actions-a4jrepeat

        Show
        phallama added a comment - richfaces component lib (a4j:repeat) I can recommend. It seems to be stable and works well for all my ui:repeat purposes. http://docs.jboss.org/richfaces/latest_4_X/Component_Reference/en-US/html/chap-Component_Reference-Tables_and_grids.html#sect-Component_Reference-Actions-a4jrepeat
        Hide
        rogerk added a comment -

        I've created a new issue: http://java.net/jira/browse/JAVASERVERFACES-2717
        and will investigate proposed solution.

        Show
        rogerk added a comment - I've created a new issue: http://java.net/jira/browse/JAVASERVERFACES-2717 and will investigate proposed solution.
        Hide
        dzwink added a comment -

        Thank you rogerk!

        Show
        dzwink added a comment - Thank you rogerk!

          People

          • Assignee:
            Unassigned
            Reporter:
            phallama
          • Votes:
            10 Vote for this issue
            Watchers:
            9 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: