ICEfaces
  1. ICEfaces
  2. ICE-7007

Support user-specified Multi-Column Sorting for ace:dataTable

    Details

    • Type: New Feature New Feature
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 2.1-Beta2, 3.0
    • Component/s: ACE-Components
    • Labels:
      None
    • Environment:
      ICEfaces 2.1, ace:dataTable
    • Assignee Priority:
      P2
    • Affects:
      Documentation (User Guide, Ref. Guide, etc.), Sample App./Tutorial

      Description

      Add  optional  support  for  user-specified  multi-column  sorting  of  dataTable  rows. This feature is enabled with the (existing) ace:column "sortBy" attribute. Any visible columns in the dataTable can be included in a multi-column sort as described below:
       
      - To  control  which  columns  are  sorted,  user  will  hold  the  CTRL  (or   Command  on  Mac)  modifier  key  then  click  on  either  the  up  or   down  sort  arrow  in  the  column  header  to  add  the  clicked  column   to  the  current  multi-column  sort.  
        
      - The  clicked  sort  arrow  will  become  highlighted  or  depressed   to  indicate  the  current  sort  direction  (ascending  or   descending).  

      - Columns  are  added  to  the  multi-column  sort  in  the  order  they   are    CTRL/Command-­‐clicked  on.  The  first  column  clicked  will   be  sorted  first,  then  the  second  column  clicked  will  be  sorted   within  the  sort  result  of  the  first  column,  etc.  etc.  

      - Once  more  than  one  column  is  active  in  the  sort,  all  active   columns  (including  the  first  column)  will  have  a  number  (1,  2,   3,  etc.)  representing  their  sort  order  sequence  displayed  in   their  header  region. If only a single column in included in the sort (single-column sort), then no number is displayed in the header for the sort order sequence.   

      - CTRL/Command  clicking  on  the  none-active  sort  arrow  (the   arrow  opposite  the  currently  selected/highlighted/depressed   arrow)  on  a  column  that  is  already  active  in  the  sort  will   change  that  column's  sort  order  (ascending/descending)   without  affecting  its  previously  established  order  in  the  multi-column  sort  sequence.    

      - Without  holding  a  modifier  key  (CTRL/Command),    clicking  on   either  the  up  or  down  sort  arrow  will  result  in  a  single  column  sort   on  the  clicked  column  being  established,  cancelling  any  other   previously  established  single  or  multi-­‐column  sort.  

      - The  sort  will  be  reprocessed  each  time  the  sort  operation  is   modified,  either  by  adding  or  removing  a  column,  or  by  changing   the  sort  order  (ascending/descending)  on  a  column.  

      - Sortable  columns  will  dynamically  display  up/down  sort  arrows  in   the  header  region  of  the  column  when  the  mouse  is  hovered  over   the  column  header  region  (or  the  column  header  has  keyboard   focus).  The  sort  arrow  arrows  will  hide  automatically  when  the   mouse  or  focus  is  outside  the  column  header,  so  long  as  the   column  is  not  part  of  an  active  sort.  Columns  that  are  included  in   an  active  sort  will  have  their  sort  arrows  (and  column  sort  order   sequence  indicator  if  part  of  a  multi-­‐column  sort)  displayed   regardless  of  the  current  mouse/focus  position.    

      - Changing  the  sort  criteria  will  also  be  supported  as  an  atomic   operation  (all  changes  processed  at  once  instead  of  incrementally) in  the  popup  "Table  Config.  Pane"  (see ICE-7005).

      - Sort  criteria  is  submitted  to  server  for  processing  (and  optionally   to  be  persisted  across  user-­‐sessions).

      - The actual sorting is completed on the server, either  via  a default  Java-based  sort handler implementation (included with the component),  or  via  deferral  to  a  data  provider  (db  query-based  implementation).  The intention of the handler-based sort implementation approach is to enable future replacement or refinement of the sort algorithm implementation by application developers, etc.

      - Client-­‐side  sorting  is  NOT  required.

        Issue Links

          Activity

          Hide
          Arturo Zambrano added a comment -

          committed back-end multi-column sorting support at revision 25394

          Show
          Arturo Zambrano added a comment - committed back-end multi-column sorting support at revision 25394
          Hide
          Nils Lundquist added a comment -

          Altered header styling in preparation for MultiColumnSorting

          Show
          Nils Lundquist added a comment - Altered header styling in preparation for MultiColumnSorting
          Hide
          Nils Lundquist added a comment -

          r25460 - Added fully working prototype. Added singleSort attribute to allow disabling the new multi sort functionality.

          Show
          Nils Lundquist added a comment - r25460 - Added fully working prototype. Added singleSort attribute to allow disabling the new multi sort functionality.
          Hide
          Ken Fyten added a comment -

          After reviewing the current UI implementation I have the following suggestions:

          Trying to fit both the up/dwn arrows and the digit(s) in the same vertical column isn't going to work. The arrows are too small, and it forces the column header to be taller than some applications might like.
          I think we should consider the following simpler layout instead:

          1. Each column header has a more substantial solid wedge-style up/dwn arrow, with the digit on the right side, either centered between the arrows, or elevated in more of a superscript layout (smaller and elevated). See the attached image for an example of the more substantial "wedge" arrows. We might want to leave a bit more whitespace between the arrows for more precise clicking of them.

          2. The styling should be such that the arrows are a more subdued (light grey?) shade when no sort is selected. As the use clicks on an arrow to select a sort order, it will become a darker shade (black). The digit appears only when a multi-col sort is in effect, and then is the dark shade (black).

          Show
          Ken Fyten added a comment - After reviewing the current UI implementation I have the following suggestions: Trying to fit both the up/dwn arrows and the digit(s) in the same vertical column isn't going to work. The arrows are too small, and it forces the column header to be taller than some applications might like. I think we should consider the following simpler layout instead: 1. Each column header has a more substantial solid wedge-style up/dwn arrow, with the digit on the right side, either centered between the arrows, or elevated in more of a superscript layout (smaller and elevated). See the attached image for an example of the more substantial "wedge" arrows. We might want to leave a bit more whitespace between the arrows for more precise clicking of them. 2. The styling should be such that the arrows are a more subdued (light grey?) shade when no sort is selected. As the use clicks on an arrow to select a sort order, it will become a darker shade (black). The digit appears only when a multi-col sort is in effect, and then is the dark shade (black).
          Hide
          Ken Fyten added a comment -

          After reviewing the latest implementation I have the following further comments:

          1. Since one of the goals of moving the digit to the right side was to be able to fit the sort controls in a shorter column header, for cases when folks are using smaller fonts, for example, I think we should reduce the whitespace between the arrows so that they do not take up any more vertical space than the digit itself (or maybe just 1-2 pixels more, depending on aesthetics).

          2. We should remove the '-' from displaying at all if a column isn't part of a multi-column sort. The digit should only appear if more than a single column sort is active (2 or more), not for single column sorts.

          3. Also, we should drop the affect on the digit on hover and just have it be black like the active arrow when it's displayed.

          4. Also, adopt the styling for the column header (darker shading) for columns active in the sort.

          5. Finally, the arrows should be focusable with the keyboard (there maybe ARIA roles for these, not sure).

          Show
          Ken Fyten added a comment - After reviewing the latest implementation I have the following further comments: 1. Since one of the goals of moving the digit to the right side was to be able to fit the sort controls in a shorter column header, for cases when folks are using smaller fonts, for example, I think we should reduce the whitespace between the arrows so that they do not take up any more vertical space than the digit itself (or maybe just 1-2 pixels more, depending on aesthetics). 2. We should remove the '-' from displaying at all if a column isn't part of a multi-column sort. The digit should only appear if more than a single column sort is active (2 or more), not for single column sorts. 3. Also, we should drop the affect on the digit on hover and just have it be black like the active arrow when it's displayed. 4. Also, adopt the styling for the column header (darker shading) for columns active in the sort. 5. Finally, the arrows should be focusable with the keyboard (there maybe ARIA roles for these, not sure).
          Hide
          Nils Lundquist added a comment - - edited

          1, 2 and 3 were just added in r25495.
          4, I'll do following my current push to get the configPanel layout perfect.

          5, is going to be problematic, and if ARIA is necessary, may require redesign for individual up/down sort icons as link elements; rather than the control itself being clickable and the sort icons being spans. I'm currently attempting some tricks up my sleeve and hope they're successful. (Tabbable directions that trigger appropriate pseduo-clicks to the parent control element.)

          I also notice in the above description we say that the header would be focusable. If we were to pursue this form of KB control, it would be a little easier to code, though less intuitive because we'd have to rely on use of the up/down or another bidirectional KB control scheme to indicate sort events.

          Show
          Nils Lundquist added a comment - - edited 1, 2 and 3 were just added in r25495. 4, I'll do following my current push to get the configPanel layout perfect. 5, is going to be problematic, and if ARIA is necessary, may require redesign for individual up/down sort icons as link elements; rather than the control itself being clickable and the sort icons being spans. I'm currently attempting some tricks up my sleeve and hope they're successful. (Tabbable directions that trigger appropriate pseduo-clicks to the parent control element.) I also notice in the above description we say that the header would be focusable. If we were to pursue this form of KB control, it would be a little easier to code, though less intuitive because we'd have to rely on use of the up/down or another bidirectional KB control scheme to indicate sort events.
          Hide
          Nils Lundquist added a comment -

          My trick mentioned above was successful and committed in r25508.
          The individual arrows are now kb-navigable anchors, that when space or enter is pressed, fakes a click to its clickable parent container, at a injected click Y position that would indicate the correct direction.

          Show
          Nils Lundquist added a comment - My trick mentioned above was successful and committed in r25508. The individual arrows are now kb-navigable anchors, that when space or enter is pressed, fakes a click to its clickable parent container, at a injected click Y position that would indicate the correct direction.
          Hide
          Ken Fyten added a comment - - edited

          Just reviewed the latest commit (svn rev#25546) and found the following issues:

          1. When the comp-suite sorting demo page is first loaded, the sort control as messed up (see attached image). They correct themselves after the first sort arrow is clicked (repeated on multiple browsers).

          2. When selecting multiple column sort via Ctrl/Command click, if you have more than 1 column in the sort, if you Ctrl/Command click the opposite arrow of a column that is already in the sort, instead of switching that column to the opposite sort order (asc/desc) based on the arrow that was clicked (and preserving it's order in the sort order), it is unsorting the column, which loses it's place in the current sort order. If you Ctrl/Command click the arrow again it sorts it correctly, but appends it to the end of the sort order. To reproduce:

          a. Open the Sorting demo page in comp-suite.
          b. click the up arrow on the Name column.
          c. Ctrl/Command click the down arrow on the Accel column.
          d. Ctrl/Command click the up arrow on the MPG column.
          e. Ctrl/Command click the up arrow on the Accel column. Note that the Accel column is no longer included in the sort. What should have happened is that the Accel column remained as col 2 in the sort, but it's sort direction changed from Desc. to Asc.

          3. I think it would be better to add another 2-4 pixels of whitespace between the up/dwn arrow, and to just centre the digit in the vertical space between the two arrow buttons.

          4. The digit is appearing even in a single column sort, the spec. indicates that it should only appear if more than one column is included in the sort.

          Show
          Ken Fyten added a comment - - edited Just reviewed the latest commit (svn rev#25546) and found the following issues: 1. When the comp-suite sorting demo page is first loaded, the sort control as messed up (see attached image). They correct themselves after the first sort arrow is clicked (repeated on multiple browsers). 2. When selecting multiple column sort via Ctrl/Command click, if you have more than 1 column in the sort, if you Ctrl/Command click the opposite arrow of a column that is already in the sort, instead of switching that column to the opposite sort order (asc/desc) based on the arrow that was clicked (and preserving it's order in the sort order), it is unsorting the column, which loses it's place in the current sort order. If you Ctrl/Command click the arrow again it sorts it correctly, but appends it to the end of the sort order. To reproduce: a. Open the Sorting demo page in comp-suite. b. click the up arrow on the Name column. c. Ctrl/Command click the down arrow on the Accel column. d. Ctrl/Command click the up arrow on the MPG column. e. Ctrl/Command click the up arrow on the Accel column. Note that the Accel column is no longer included in the sort. What should have happened is that the Accel column remained as col 2 in the sort, but it's sort direction changed from Desc. to Asc. 3. I think it would be better to add another 2-4 pixels of whitespace between the up/dwn arrow, and to just centre the digit in the vertical space between the two arrow buttons. 4. The digit is appearing even in a single column sort, the spec. indicates that it should only appear if more than one column is included in the sort.
          Hide
          Nils Lundquist added a comment - - edited

          1. I would guess this is some rendering bug due to the blank character that is written there. I can't reproduce it on FF, Chome or Safari though.

          2. This is due to the click being delivered to a single JS handler. Additional logic needs to be added to account for meta-clicking the same direction as opposed the opposite.

          4. How is the user then supposed to know at first sort that a table is multi sortable at all? This looks rather odd as well because the space for the integer remain must remain reserved, but goes unused unless the user knows to start meta-clicking sort controls.

          Show
          Nils Lundquist added a comment - - edited 1. I would guess this is some rendering bug due to the blank character that is written there. I can't reproduce it on FF, Chome or Safari though. 2. This is due to the click being delivered to a single JS handler. Additional logic needs to be added to account for meta-clicking the same direction as opposed the opposite. 4. How is the user then supposed to know at first sort that a table is multi sortable at all? This looks rather odd as well because the space for the integer remain must remain reserved, but goes unused unless the user knows to start meta-clicking sort controls.
          Hide
          Nils Lundquist added a comment -

          Issue 2 is fixed in r25449.

          Show
          Nils Lundquist added a comment - Issue 2 is fixed in r25449.
          Hide
          Nils Lundquist added a comment -

          Gap between sort arrows increased in r25550

          Show
          Nils Lundquist added a comment - Gap between sort arrows increased in r25550
          Hide
          Nils Lundquist added a comment -

          r25560 - Multisort from Table Config Pane. (Note table config pane currently has a bug where a style tag gets written as a string literal folllowing a config pane submit.)

          Show
          Nils Lundquist added a comment - r25560 - Multisort from Table Config Pane. (Note table config pane currently has a bug where a style tag gets written as a string literal folllowing a config pane submit.)
          Hide
          Ken Fyten added a comment -

          As of svn rvn# 25874 there is an outstanding Known Issue with this feature:

          Column Sorting & Column Config Panel Inconsistency - Presently changes made to the column sorting on the table configuration panel are reflected in the header sort controls, but not vice versa; despite rerendering the config panel during the header-initiated sort request. We speculate this is related to a state saving issue we have noticed elsewhere and are seeeking to rectify.

          Show
          Ken Fyten added a comment - As of svn rvn# 25874 there is an outstanding Known Issue with this feature: Column Sorting & Column Config Panel Inconsistency - Presently changes made to the column sorting on the table configuration panel are reflected in the header sort controls, but not vice versa; despite rerendering the config panel during the header-initiated sort request. We speculate this is related to a state saving issue we have noticed elsewhere and are seeeking to rectify.
          Hide
          Nils Lundquist added a comment -

          Works as expected. Bug free as far as is known.

          Only issue related is that the sort order set on the column headers is not rendered on the controls in the panel.
          ICE-7005 will remain open until that issue is resolved.

          Show
          Nils Lundquist added a comment - Works as expected. Bug free as far as is known. Only issue related is that the sort order set on the column headers is not rendered on the controls in the panel. ICE-7005 will remain open until that issue is resolved.

            People

            • Assignee:
              Nils Lundquist
              Reporter:
              Ken Fyten
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: