javaserverfaces
  1. javaserverfaces
  2. JAVASERVERFACES-1991

Submitted value of UIInput gets lost inside composite components

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Cannot Reproduce
    • Affects Version/s: 2.0.3, 2.0.4, 2.1.0
    • Fix Version/s: 2.1.11, 2.2.0-m05
    • Labels:
      None
    • Environment:

      JDK 1.6, Tomcat 6

    • Status Whiteboard:
      Hide

      size_large importance_medium

      Show
      size_large importance_medium
    • Tags:

      Description

      When a UIInput component are nested inside composite components, its submittedValue gets lost and is not rendered on validation errors.

      This simple example fails:
      <myCC:layout>
      <h:inputText>
      <f:validateLength minimum="20"/>
      </h:inputText>
      </myCC:layout>

      The issue is present if the composite component inserts its childs with <cc:insertChildren />. When using facets with <cc:renderFacet /> it works correctly.

      This issue seems to have a strong relation to JAVASERVERFACES-1825 because the conditions and possible workarounds are very similar.
      Both bugs are really blockers. Composite components become useless this way.

        Issue Links

          Activity

          Mathias Werlitz created issue -
          Hide
          Mathias Werlitz added a comment -

          The example shows a simple h:inputText and a h:inputText nested inside a very simple composite component.
          If you enter a short text into both fields and submit the form, the submitted value of the simple h:inputText is redisplayed and the submitted value of the h:inputText nested inside the composite component is NOT on validation errors.

          Show
          Mathias Werlitz added a comment - The example shows a simple h:inputText and a h:inputText nested inside a very simple composite component. If you enter a short text into both fields and submit the form, the submitted value of the simple h:inputText is redisplayed and the submitted value of the h:inputText nested inside the composite component is NOT on validation errors.
          Ed Burns made changes -
          Field Original Value New Value
          Status Whiteboard size_large importance_medium
          Hide
          tlind added a comment -

          This seems to be a duplicate of JAVASERVERFACES-1784. I am also experiencing this problem and it basically makes composite components that contain input fields a no-go.

          Show
          tlind added a comment - This seems to be a duplicate of JAVASERVERFACES-1784 . I am also experiencing this problem and it basically makes composite components that contain input fields a no-go.
          Hide
          Mathias Werlitz added a comment -

          Well it seems that JAVASERVERFACES-2040 is the root cause of this problem.
          My proposed patch will also fix this issue.

          Show
          Mathias Werlitz added a comment - Well it seems that JAVASERVERFACES-2040 is the root cause of this problem. My proposed patch will also fix this issue.
          Ed Burns made changes -
          Link This issue depends on JAVASERVERFACES-2040 [ JAVASERVERFACES-2040 ]
          Hide
          rogerk added a comment -

          Ok I am able to duplicate this problem.

          Show
          rogerk added a comment - Ok I am able to duplicate this problem.
          Hide
          joserodolfo.freitas added a comment -

          I workaround this problem putting <cc:insertChildren /> inside a h:panelGroup

              <h:panelGroup >        
                <cc:insertChildren/>        
              </h:panelGroup>
          
          Show
          joserodolfo.freitas added a comment - I workaround this problem putting <cc:insertChildren /> inside a h:panelGroup <h:panelGroup > <cc:insertChildren/> </h:panelGroup>
          Hide
          Adrian Gygax added a comment -

          <ui:fragment> worked for me as well as a workaround with the benefit that it doesn't render any addiontal HTML:

          <ui:fragment>        
            <cc:insertChildren/>        
          </ui:fragment>
          
          Show
          Adrian Gygax added a comment - <ui:fragment> worked for me as well as a workaround with the benefit that it doesn't render any addiontal HTML: <ui:fragment> <cc:insertChildren/> </ui:fragment>
          Hide
          conpem added a comment -

          Hi Mathias!
          I need help on this issue urgently. you write there is a patch that solves this problem. we are running with 2.0.4_b for now and no plans on upgrading jsf.
          I created an issue: http://java.net/jira/browse/JAVASERVERFACES-2216 which regards the same bug about cc:insertChildren and using the wrap h:panelGroup
          please if you have time look through it!

          Best.

          Show
          conpem added a comment - Hi Mathias! I need help on this issue urgently. you write there is a patch that solves this problem. we are running with 2.0.4_b for now and no plans on upgrading jsf. I created an issue: http://java.net/jira/browse/JAVASERVERFACES-2216 which regards the same bug about cc:insertChildren and using the wrap h:panelGroup please if you have time look through it! Best.
          Hide
          Ed Burns added a comment -

          Because a workaround exists, we can downgrade this from blocker status.

          Show
          Ed Burns added a comment - Because a workaround exists, we can downgrade this from blocker status.
          Ed Burns made changes -
          Priority Blocker [ 1 ] Major [ 3 ]
          Hide
          anadollu added a comment - - edited

          Hi Ed,

          Please don't downgrade this issue from blocker, Becouse workaround is not valid for all versions. 2.1.5 version don't work with this workaround. In my opinion, this issue should be considered as blocker.

          Thanks.

          Show
          anadollu added a comment - - edited Hi Ed, Please don't downgrade this issue from blocker, Becouse workaround is not valid for all versions. 2.1.5 version don't work with this workaround. In my opinion, this issue should be considered as blocker. Thanks.
          Ed Burns made changes -
          Priority Major [ 3 ] Blocker [ 1 ]
          Hide
          Mathias Werlitz added a comment -

          The problem is that state saving of composite components is broken in Mojarra. I don't understand why this fundamental problem doesn't get fixed. It's already open for 10 months. I explained in detail what goes wrong and supplied a patch for the root cause of the problem JAVASERVERFACES-2040. This will also fix this issue.

          Show
          Mathias Werlitz added a comment - The problem is that state saving of composite components is broken in Mojarra. I don't understand why this fundamental problem doesn't get fixed. It's already open for 10 months. I explained in detail what goes wrong and supplied a patch for the root cause of the problem JAVASERVERFACES-2040 . This will also fix this issue.
          Ed Burns made changes -
          Hide
          Ed Burns added a comment -

          Here's the cause of the problem:

          On render, we have a new instance for the UIInput inside the CC, whereas
          we have the same instance for the UIInput outside the CC.

          The workaround, which enables me to de-prioritize this from Blocker to Major, is to use value binding or component binding in the case of the inner component.

          I'll continue to work on this as high priority, though.

          Show
          Ed Burns added a comment - Here's the cause of the problem: On render, we have a new instance for the UIInput inside the CC, whereas we have the same instance for the UIInput outside the CC. The workaround, which enables me to de-prioritize this from Blocker to Major, is to use value binding or component binding in the case of the inner component. I'll continue to work on this as high priority, though.
          Ed Burns made changes -
          Priority Blocker [ 1 ] Major [ 3 ]
          Hide
          Ed Burns added a comment -

          Believe it or not, the reason this one is a problem is because of our hack approach for the implementation to cc:insertChildren and cc:insertFacet.

          It's a duplicate of JAVASERVERFACES-1985.

          Show
          Ed Burns added a comment - Believe it or not, the reason this one is a problem is because of our hack approach for the implementation to cc:insertChildren and cc:insertFacet. It's a duplicate of JAVASERVERFACES-1985 .
          Ed Burns made changes -
          Link This issue duplicates JAVASERVERFACES-1985 [ JAVASERVERFACES-1985 ]
          Ed Burns made changes -
          Assignee Ed Burns [ edburns ] Manfred Riem [ mriem ]
          Ed Burns made changes -
          Assignee Manfred Riem [ mriem ] Ed Burns [ edburns ]
          Hide
          Ed Burns added a comment -

          I don't understand why InsertChildrenHandler.apply() is called once on
          the initial render and twice on the postback. That seems incorrect.

          Show
          Ed Burns added a comment - I don't understand why InsertChildrenHandler.apply() is called once on the initial render and twice on the postback. That seems incorrect.
          Hide
          Ed Burns added a comment -

          I don't understand why InsertChildrenHandler.apply() is called once on
          the initial render and twice on the postback. That seems incorrect.

          Show
          Ed Burns added a comment - I don't understand why InsertChildrenHandler.apply() is called once on the initial render and twice on the postback. That seems incorrect.
          Hide
          Mathias Werlitz added a comment -

          Hi Ed,

          yes, JAVASERVERFACES-1985 is the problem here and is part of the problem of JAVASERVERFACES-2040. Please see my analysis of JAVASERVERFACES-2040. InsertChildrenHandler.apply() is added and called twice because the component tree is rebuild a second time before rendering.

          My patch for JAVASERVERFACES-2040 will fix (at least a part of) JAVASERVERFACES-1985. It does not remove the "hack approach" but the components will not be recreated and the "listener hack" will only executed once.

          Show
          Mathias Werlitz added a comment - Hi Ed, yes, JAVASERVERFACES-1985 is the problem here and is part of the problem of JAVASERVERFACES-2040 . Please see my analysis of JAVASERVERFACES-2040 . InsertChildrenHandler.apply() is added and called twice because the component tree is rebuild a second time before rendering. My patch for JAVASERVERFACES-2040 will fix (at least a part of) JAVASERVERFACES-1985 . It does not remove the "hack approach" but the components will not be recreated and the "listener hack" will only executed once.
          Manfred Riem made changes -
          Tags composite
          Manfred Riem made changes -
          Component/s implementation [ 10535 ]
          Manfred Riem made changes -
          Component/s validation [ 14504 ]
          Hide
          Manfred Riem added a comment -

          Using the attached example I am unable to reproduce this on 2.1.11

          Show
          Manfred Riem added a comment - Using the attached example I am unable to reproduce this on 2.1.11
          Manfred Riem made changes -
          Status Open [ 1 ] Resolved [ 5 ]
          Fix Version/s 2.1.11 [ 15538 ]
          Resolution Cannot Reproduce [ 5 ]
          Manfred Riem made changes -
          Fix Version/s 2.2-m05 [ 15548 ]
          Manfred Riem made changes -
          Status Resolved [ 5 ] Closed [ 6 ]
          Hide
          Mathias Werlitz added a comment -

          Yes, it seems this issue has been fixed with 2.1.11.

          Show
          Mathias Werlitz added a comment - Yes, it seems this issue has been fixed with 2.1.11.

            People

            • Assignee:
              Ed Burns
              Reporter:
              Mathias Werlitz
            • Votes:
              15 Vote for this issue
              Watchers:
              8 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: