ICEfaces
  1. ICEfaces
  2. ICE-11001

ace:dataTable child row expansion issue.

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: EE-3.3.0.GA_P02, EE-3.3.0.GA_P03
    • Fix Version/s: EE-3.3.0.GA_P04, 4.2.BETA, 4.2
    • Component/s: ACE-Components
    • Labels:
      None
    • Environment:
      Tomcat 7/8, All browsers. ICEfaces ee-3.3.0 maintenance branch

      Description

      An ace:dataTable with multiple levels of child rows can not be re-expanded after expanding to the deepest level.
      This can be demonstrated with the QA dataTable /views/configPanelTest.jsf
      1.) Load the test app ( /views/configPanelTest.jsf) using ee-3.3.0 maintenance branch dataTable
      2.) Expand the last row in the table twice to reveal the sub-rows.
      3.) Contract the rows to the parent level
      4.) Try to expand the rows again, the last child row does not expand.

        Activity

        Hide
        Judy Guglielmin added a comment -

        fails with both 3.3.0-P02 and P03.

        Show
        Judy Guglielmin added a comment - fails with both 3.3.0-P02 and P03.
        Hide
        Arturo Zambrano added a comment -

        Added 4.2 target, since I would reproduce the issue with the 4.x trunk as well.

        Show
        Arturo Zambrano added a comment - Added 4.2 target, since I would reproduce the issue with the 4.x trunk as well.
        Hide
        Arturo Zambrano added a comment -

        r48952 fix to restore visibility to child rows that were previously hidden in the client, after a parent row is expanded
        r48953: committed fix to the 4.x trunk

        The issue was that there was a mismatch in child rows states between the server-side state and the client-side state. After contracting a row, some javascript in the client adds "display:none;" to all its child rows, and after expanding that same row again, this styling was not removed from its child rows. This fix adds a function does just that: it removes "display:none;" from all first-level child rows of a particular row, and it calls itself recursively on child rows that are also expanded.

        Show
        Arturo Zambrano added a comment - r48952 fix to restore visibility to child rows that were previously hidden in the client, after a parent row is expanded r48953: committed fix to the 4.x trunk The issue was that there was a mismatch in child rows states between the server-side state and the client-side state. After contracting a row, some javascript in the client adds "display:none;" to all its child rows, and after expanding that same row again, this styling was not removed from its child rows. This fix adds a function does just that: it removes "display:none;" from all first-level child rows of a particular row, and it calls itself recursively on child rows that are also expanded.
        Hide
        Liana Munroe added a comment - - edited

        Verified ICEfaces 4 trunk, ee-3.3.0 maintenance branch r48953. Tomcat 8, IE edge, 11, 10, 9, 8, 7, FF 43, Chrome 50 with test case and regression tests. New test app /ICE-11001.jsf has been checked in.

        In the QA test app /rowExpansionTest.jsf the most inner child rows contain a panel. If you expand the row to the inner-most child, then contract the parent, the panel stays visible. This is also seen when testing with EE-3.3.0 p02 and EE-4.0.0 libs.
        Is this an issue?

        Show
        Liana Munroe added a comment - - edited Verified ICEfaces 4 trunk, ee-3.3.0 maintenance branch r48953. Tomcat 8, IE edge, 11, 10, 9, 8, 7, FF 43, Chrome 50 with test case and regression tests. New test app / ICE-11001 .jsf has been checked in. In the QA test app /rowExpansionTest.jsf the most inner child rows contain a panel. If you expand the row to the inner-most child, then contract the parent, the panel stays visible. This is also seen when testing with EE-3.3.0 p02 and EE-4.0.0 libs. Is this an issue?
        Hide
        Arturo Zambrano added a comment -

        It seems like an issue. I'll take a look.

        Show
        Arturo Zambrano added a comment - It seems like an issue. I'll take a look.
        Hide
        Arturo Zambrano added a comment -

        I examined that last issue, and it's not really an issue. It's just the way things work.

        In that test page, the table uses both row expansion and panel expansion, and it's the expansion panel that remains open after contracting the main row. There is only one expansion panel associated with one main row. Because there's only one expansion toggler for both types on expansion, and this table has both types of expansion, then the very last expansion toggler is used for the panel expansion, while all the others are used for row expansion. So, contracting the parent row also contracts all child rows but not the expansion panel. If we also contracted the expansion panel, then we wouldn't be allowing the possibility of only showing the expansion panels (without showing the child rows). There could be a counter argument that maybe the user would intend to close all the child rows and the expansion panel when contracting the main row, but that really would depend on how each table is set up, how many child rows it has, how it's meant to be used, etc. It's better to opt to keep both types of expansion separate and thus allow for more possibilities.

        Show
        Arturo Zambrano added a comment - I examined that last issue, and it's not really an issue. It's just the way things work. In that test page, the table uses both row expansion and panel expansion, and it's the expansion panel that remains open after contracting the main row. There is only one expansion panel associated with one main row. Because there's only one expansion toggler for both types on expansion, and this table has both types of expansion, then the very last expansion toggler is used for the panel expansion, while all the others are used for row expansion. So, contracting the parent row also contracts all child rows but not the expansion panel. If we also contracted the expansion panel, then we wouldn't be allowing the possibility of only showing the expansion panels (without showing the child rows). There could be a counter argument that maybe the user would intend to close all the child rows and the expansion panel when contracting the main row, but that really would depend on how each table is set up, how many child rows it has, how it's meant to be used, etc. It's better to opt to keep both types of expansion separate and thus allow for more possibilities.

          People

          • Assignee:
            Arturo Zambrano
            Reporter:
            Liana Munroe
          • Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: