ICEfaces
  1. ICEfaces
  2. ICE-8067

Issue with using ace:confimationDialog in an ace:dataTable row

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: EE-3.0.0.GA
    • Fix Version/s: 3.1.0.BETA2, 3.1
    • Component/s: ACE-Components
    • Labels:
      None
    • Environment:
      All
    • Assignee Priority:
      P2

      Description

      An ace:confirmationDialog is set for each row in an ace:dataTable. The dialog is linked to a commandButton and if the dialog is confirmed the row will be removed from the dataTable.

      The issue lies after a row has been removed. When a row is removed and then another row is selected to be deleted, the confirmationDialog is displayed for a quick moment and then is gone. Clicking the button again will show the dialog correctly. This only happens after a row is removed from the table.

        Activity

        Arran Mccullough created issue -
        Arran Mccullough made changes -
        Field Original Value New Value
        Salesforce Case [5007000000MFL7d]
        Hide
        Arran Mccullough added a comment -

        Attached test case to reproduce issue.

        Steps:

        • Load welcomeICEfaces.jsf
        • Click on the Delete button for the first row.
        • The confirmation dialog is shown, click on the Yes button.
        • The first row is removed.
        • Click on the Delete button for the new first row.
        • The dialog is displayed for an instance.
        • Clicking on the Delete button again shows it completely.
        Show
        Arran Mccullough added a comment - Attached test case to reproduce issue. Steps: Load welcomeICEfaces.jsf Click on the Delete button for the first row. The confirmation dialog is shown, click on the Yes button. The first row is removed. Click on the Delete button for the new first row. The dialog is displayed for an instance. Clicking on the Delete button again shows it completely.
        Arran Mccullough made changes -
        Attachment Case11220Example.zip [ 14372 ]
        Attachment Case11220Example.war [ 14373 ]
        Ken Fyten made changes -
        Fix Version/s 3.1.0.BETA2 [ 10336 ]
        Fix Version/s 3.1 [ 10312 ]
        Assignee Priority P2
        Assignee Arturo Zambrano [ artzambrano ]
        Hide
        Arturo Zambrano added a comment -

        This problem can be easily avoided by appending "return false;" at the end of the onclick attribute of the h:commandButton used to display the dialog. This situation no longer happens if using the latest build.

        The problem occurred in the test app because the h:commandButton used to display the dialog was making a submit (as is normal) and thus the server was sending a response with an update for the whole table, so the original HTML elements used to display the dialog the first time were immediately replaced. With "return false;", no submit is made to the server and thus there are no updates to apply while the dialog is showing.

        Now, even without using "return false;" in the onclick attribute of the button, ideally there shouldn't be an update of the whole table if the user didn't directly changed the state of the application. I analyzed the response and I noticed that there's this node '<div style="display:none;">2</div>' at the very end of the table markup, which seems to increase at every request. This is the only thing that changes in the markup when clicking the button to display the dialog. Since, this node doesn't have its own client id, then the parent element (root node of the table component) has to be updated, and thus the whole table markup is updated and the original dialog nodes disappear. In the latest build this is no longer the case, so these unnecessary updates do not take place any more.

        The only situation where something like this can still occur is when the first page of the application that is loaded by the user is this page (thus starting a new session) and the server has to use the jsessionid parameter in the url. Then, when this parameter is no longer necessary, the url of the containing form will change, triggering an update for the whole form. However, this is avoided by simply using "return false;", as explained above.

        Show
        Arturo Zambrano added a comment - This problem can be easily avoided by appending "return false;" at the end of the onclick attribute of the h:commandButton used to display the dialog. This situation no longer happens if using the latest build. The problem occurred in the test app because the h:commandButton used to display the dialog was making a submit (as is normal) and thus the server was sending a response with an update for the whole table, so the original HTML elements used to display the dialog the first time were immediately replaced. With "return false;", no submit is made to the server and thus there are no updates to apply while the dialog is showing. Now, even without using "return false;" in the onclick attribute of the button, ideally there shouldn't be an update of the whole table if the user didn't directly changed the state of the application. I analyzed the response and I noticed that there's this node '<div style="display:none;">2</div>' at the very end of the table markup, which seems to increase at every request. This is the only thing that changes in the markup when clicking the button to display the dialog. Since, this node doesn't have its own client id, then the parent element (root node of the table component) has to be updated, and thus the whole table markup is updated and the original dialog nodes disappear. In the latest build this is no longer the case, so these unnecessary updates do not take place any more. The only situation where something like this can still occur is when the first page of the application that is loaded by the user is this page (thus starting a new session) and the server has to use the jsessionid parameter in the url. Then, when this parameter is no longer necessary, the url of the containing form will change, triggering an update for the whole form. However, this is avoided by simply using "return false;", as explained above.
        Arturo Zambrano made changes -
        Status Open [ 1 ] Resolved [ 5 ]
        Resolution Fixed [ 1 ]
        Ken Fyten made changes -
        Status Resolved [ 5 ] Closed [ 6 ]

          People

          • Assignee:
            Arturo Zambrano
            Reporter:
            Arran Mccullough
          • Votes:
            1 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: