ICEfaces
  1. ICEfaces
  2. ICE-10879

input fields not updated on Ajax update unless they are also "executed"

          Details

          • Type: Bug Bug
          • Status: Closed
          • Priority: Minor Minor
          • Resolution: Won't Fix
          • Affects Version/s: EE-4.0.0.GA, EE-3.3.0.GA_P03
          • Fix Version/s: EE-4.1.0.GA, EE-3.3.0.GA_P04
          • Component/s: Framework
          • Labels:
            None
          • Environment:
            All, ACE, MOBI
          • Assignee Priority:
            P1
          • Support Case References:
          • Workaround Exists:
            Yes
          • Workaround Description:
            Hide
            It works if you include the comp id in the execite attribute:
            execute="@this bodyTextarea" render="bodyTextarea"
            Show
            It works if you include the comp id in the execite attribute: execute="@this bodyTextarea" render="bodyTextarea"

            Description

            A page includes an inputText field and a button which clears out the field on the server side via an actionListener

            The button uses an ajax tag with the following set (bodyTextarea is the id of the input field):
            execute="@this" render="bodyTextarea"

            On click of button any text entered into the field should be cleared out but the field is not being rendered in the update.

            This issue is reproducible with the mobi:commandButton/mobi:ajax, h:commandButton/f:ajax and ace:pushButton/ace:ajax components.

            When testing the same code in a pure JSF sample (no ICEfaces), the input field gets cleared out correctly.

              Activity

              Ascending order - Click to sort in descending order
              12 older comments
              Hide
              Permalink
              Arran Mccullough added a comment -

              Is this an ICEfaces requirement then? My main cause of confusion was that this isn't required in a basic JSF only (No ICEfaces) sample. The input field is cleared without the need to include the id of the component in the f:ajax execute tag.

              Show
              Arran Mccullough added a comment - Is this an ICEfaces requirement then? My main cause of confusion was that this isn't required in a basic JSF only (No ICEfaces) sample. The input field is cleared without the need to include the id of the component in the f:ajax execute tag.
              Hide
              Permalink
              Mircea Toma added a comment -

              I would argue that ICEfaces is doing the right thing here while with just Mojarra you get the reset of the component as a side effect because the Mojarra updates are not so granular.

              Show
              Mircea Toma added a comment - I would argue that ICEfaces is doing the right thing here while with just Mojarra you get the reset of the component as a side effect because the Mojarra updates are not so granular.
              Hide
              Permalink
              Ken Fyten added a comment -

              Re-opened for the regressions this commit has caused that are noted in ICE-10937.

              Show
              Ken Fyten added a comment - Re-opened for the regressions this commit has caused that are noted in ICE-10937.
              Hide
              Permalink
              Mircea Toma added a comment - - edited

              I revisited the initial issue and also ran the attached test case and the one QA has created. Both of these tests are working fine with the code we had before any of the fixes were applied. This issue was created with the assumption that the behaviour of the updates should match what Mojarra does when running without ICEfaces. Also there was the confusion (on my part) on what are the exact steps to reproduce.

              The difference in behaviour between Mojarra and ICEfaces is explained here http://jira.icesoft.org/browse/ICE-10879?focusedCommentId=62276&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-62276 . Also the reason why we do not need to change is here: http://jira.icesoft.org/browse/ICE-10879?focusedCommentId=62290&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-62290 .

              Also I can confirm now that f:ajax will convert the component IDs to client IDs when the AJAX behaviour JS code is rendered. For some reason I thought that this normalisation is not applied by f:ajax and that is the reason why the fixes were applied.

              So really we should just rollback the applied changes . That will also fix the side-effects that Art has discovered.

              Show
              Mircea Toma added a comment - - edited I revisited the initial issue and also ran the attached test case and the one QA has created. Both of these tests are working fine with the code we had before any of the fixes were applied. This issue was created with the assumption that the behaviour of the updates should match what Mojarra does when running without ICEfaces. Also there was the confusion (on my part) on what are the exact steps to reproduce. The difference in behaviour between Mojarra and ICEfaces is explained here http://jira.icesoft.org/browse/ICE-10879?focusedCommentId=62276&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-62276 . Also the reason why we do not need to change is here: http://jira.icesoft.org/browse/ICE-10879?focusedCommentId=62290&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-62290 . Also I can confirm now that f:ajax will convert the component IDs to client IDs when the AJAX behaviour JS code is rendered. For some reason I thought that this normalisation is not applied by f:ajax and that is the reason why the fixes were applied. So really we should just rollback the applied changes . That will also fix the side-effects that Art has discovered.
              Hide
              Permalink
              Mircea Toma added a comment -

              Rolled back fixes since they are really not necessary (see explanation above).

              Show
              Mircea Toma added a comment - Rolled back fixes since they are really not necessary (see explanation above).

                People

                • Assignee:
                  Mircea Toma
                  Reporter:
                  Arran Mccullough
                • Votes:
                  1 Vote for this issue
                  Watchers:
                  7 Start watching this issue

                  Dates

                  • Created:
                    Updated:
                    Resolved: