ICEfaces
  1. ICEfaces
  2. ICE-9859

ace:dataTable, lazy="true", used with RowStateMap and rowSelectListener does not highlight selected Row

          Details

          • Type: Bug Bug
          • Status: Closed
          • Priority: Major Major
          • Resolution: Invalid
          • Affects Version/s: EE-3.3.0.GA_P01
          • Fix Version/s: 4.0.BETA, EE-3.3.0.GA_P02, 4.0
          • Component/s: ACE-Components
          • Labels:
            None
          • Environment:
            jsf2 ace
          • Assignee Priority:
            P1
          • Salesforce Case Reference:

            Description

            1. The rowStateMap attribute of the managed bean seems to be detached of the datatable: selected items in the rowStateMap do not appear as visually selected in the datatable. When you click the Select First button, the first student is selected (both in rowStateMap and in selectedStudent), but there is no visual feedback from the datatable showing such selection.
            2. Every time you click a row in the datatable, the student is selected but it seems the load method of the studentList is getting called again and the table is refreshed, even though the data of the table hasn’t changed, and this causes the selection on the table to be lost. However, in you click the same row a second time, then the selection will work as expected.

            see attached example. page acetable.jsf shows without lazy="true" where the selected row is highlighted depending on row selected.
            page acelazytable.jsf shows problem with losing highlight of selected row. Also note the button to modify the selected Student by server-side actionListener only works when selectedStudent is in the view (on same page). acelazytable2.jsf contains attribute alwaysExecuteContents="true" which ensures the server-side actionListener is updated to the table, but still client rendering to show selected row is lost.

            addition of ace:ajax did not resolve the problem either.

              Issue Links

              blocks

              Improvement - An improvement or enhancement to an existing feature or task. ICE-9900 Update docs, showcase and qa examples for ace:dataTable to implement hashCode and equals methods

              • Major - Major loss of function.
              • Closed

                Activity

                Ascending order - Click to sort in descending order
                Hide
                Permalink
                Judy Guglielmin added a comment -

                test case

                Show
                Judy Guglielmin added a comment - test case
                Hide
                Permalink
                Judy Guglielmin added a comment -

                for assignment...

                Show
                Judy Guglielmin added a comment - for assignment...
                Hide
                Permalink
                Arturo Zambrano added a comment -

                Closing as invalid. There's really no issue to fix. The problem was in the test app.

                Two modified source files are attached that show the correct approach. Replacing either or both of them in the original test app would fix the problem.

                The original Student class was missing custom equals() and hashCode() methods, which are a requirement to work with ace:dataTable. The attached Student.java file contains these custom implementations, which help uniquely identify a data object across lifecycles. Since the lazy data table in the test app was (re)generating all the data objects at every request (in the load() method of the LazyDataModel implementation), these data objects were being created with the default hashCode() method, which returned a different value every time an object was created, even if it had the same data. This fix alone, solves the problem, since the data object itself is used as a key in the row state map to find its row state object, so the hash codes must be unique.

                Alternatively, the AceLazyBean class could be modified as suggested in the attached file to avoid regenerating the data set at every request. The original bean was regenerating the entire data set in the load() method, which is called at every request. The attached file shows how the data can be generated only once (so that we don't have new objects at every request, and they keep their original hash codes throughout the session or bean's lifetime). Instead, we prepare and return a subset of this data, based on the passed parameters like 'first' and 'pageSize'. This fix alone also solves the problem. However, both fixes are recommended.

                Show
                Arturo Zambrano added a comment - Closing as invalid. There's really no issue to fix. The problem was in the test app. Two modified source files are attached that show the correct approach. Replacing either or both of them in the original test app would fix the problem. The original Student class was missing custom equals() and hashCode() methods, which are a requirement to work with ace:dataTable. The attached Student.java file contains these custom implementations, which help uniquely identify a data object across lifecycles. Since the lazy data table in the test app was (re)generating all the data objects at every request (in the load() method of the LazyDataModel implementation), these data objects were being created with the default hashCode() method, which returned a different value every time an object was created, even if it had the same data. This fix alone, solves the problem, since the data object itself is used as a key in the row state map to find its row state object, so the hash codes must be unique. Alternatively, the AceLazyBean class could be modified as suggested in the attached file to avoid regenerating the data set at every request. The original bean was regenerating the entire data set in the load() method, which is called at every request. The attached file shows how the data can be generated only once (so that we don't have new objects at every request, and they keep their original hash codes throughout the session or bean's lifetime). Instead, we prepare and return a subset of this data, based on the passed parameters like 'first' and 'pageSize'. This fix alone also solves the problem. However, both fixes are recommended.

                  People

                  • Assignee:
                    Arturo Zambrano
                    Reporter:
                    Judy Guglielmin
                  • Votes:
                    0 Vote for this issue
                    Watchers:
                    2 Start watching this issue

                    Dates

                    • Created:
                      Updated:
                      Resolved: