Details
-
Type:
New Feature
-
Status: Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: None
-
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
- 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
- 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
- All
- Comments
- History
- Activity
- Remote Attachments
- Subversion
Altered header styling in preparation for MultiColumnSorting
r25460 - Added fully working prototype. Added singleSort attribute to allow disabling the new multi sort functionality.
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).
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).
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.
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.
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.
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.
Issue 2 is fixed in r25449.
Gap between sort arrows increased in r25550
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.)
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.
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.
committed back-end multi-column sorting support at revision 25394