Item13309: regressions in table rendering, TABLE macro and improper sorting of the table headers with initsort
Priority: Normal
Current State: Closed
Released In: 2.0.0
Target Release: major
To reproduce this, use a simple unsorted TML table such as:
| *First Heading* | *Second Heading* | *Third Heading* |
| Delta | Echo | Foxtrot |
| Golf | Hotel | India |
| November | Oscar | Papa |
| Alpha | Bravo | Charlie |
| Kilo | Lima | Mike |
| Hotel | India | Juliett |
such a simple table displays as
under 1.2 |
under 1.1.x |
|
|
- [A1] under 1.2 the table header's background is not differentiated from the table rows, this is a regression, since it visually helps understand the table's structure
- [A2]the table header's background visible under 1.1.x should be used in 1.2, or another visually helpful mean (bold is not enough, since table's contents may be in bold too)
- [A3]if a darker background is used, the 1st data row's background should be white so as to alternate colours, 2nd should be darker, 3rd white, etc.
if you click on the 1st header to sort the table, you get this
under 1.2 |
under 1.1.x |
|
|
- [B1] the alternate colours distinguishing the rows should be shown every two rows (instead, they are just moved around with the sorting)
- to avoid regressions:
- [B2] the sorted column's header should bear an indicator mentioning:
- that the table is sorted with this column
- the sorting direction
- [B3] the sorted column should show in a dimmer background colour visually distinguishing it like it does in 1.1.x
TML table with %TABLE{initsort="1" initdirection="down"}%
If you try to sort the table using:
%TABLE{initsort="1" initdirection="down"}%
| *First Heading* | *Second Heading* | *Third Heading* |
| Delta | Echo | Foxtrot |
| Golf | Hotel | India |
| November | Oscar | Papa |
| Alpha | Bravo | Charlie |
| Kilo | Lima | Mike |
| Hotel | India | Juliett |
You get:
under 1.2 |
under 1.1.x |
|
|
- [C1] the header is improperly sorted. It should not be included in the sorted rows
- [C2] if you click on the underlined "First Heading" in the middle of the rows, you see that the sorting direction changes, and that the first row "Alpha, Bravo, Charlie" (which should be a data row) does not move and acts as a header
- (duplicate of [B2]) to avoid regressions, the sorted column's header should bear an indicator mentioning:
- that the table is sorted with this column
- the sorting direction
TML table with %TABLE{initsort="1" initdirection="down"}% and %EDITTABLE{}%
If you try to sort the table using:
%TABLE{initsort="1" initdirection="down"}%
%EDITTABLE{}%
| *First Heading* | *Second Heading* | *Third Heading* |
| Delta | Echo | Foxtrot |
| Golf | Hotel | India |
| November | Oscar | Papa |
| Alpha | Bravo | Charlie |
| Kilo | Lima | Mike |
| Hotel | India | Juliett |
You get:
under 1.2 |
under 1.1.x |
|
|
- [D1] the table is not sorted at all
TML table with %TABLE{initsort="1" initdirection="up"}% and %EDITTABLE{}%
If you try to sort the table and using %EDITTABLE% macro using:
%TABLE{initsort="1" initdirection="up"}%
%EDITTABLE{}%
| *First Heading* | *Second Heading* | *Third Heading* |
| Delta | Echo | Foxtrot |
| Golf | Hotel | India |
| November | Oscar | Papa |
| Alpha | Bravo | Charlie |
| Kilo | Lima | Mike |
| Hotel | India | Juliett |
You get:
under 1.2 |
under 1.1.x |
|
|
- the table is not sorted at all
- the headers are appearing at the bottom of the table, instead of the top
- if you click on the underlined "First Heading" the table gets sorted in the following manner:
- the Headers row gets sorted with the other rows as it was a data row
- the top "Delta, Echo, Foxtrot" row does not move, acting as if it was a Header row
--
RaulFRodriguez - 17 Mar 2015
There are multiple issues reported here, which makes it hard to deal with. Let's try and identify which are really problems, so we can generate individual tasks for them.
Clean checkout, pseudo-install developer, all plugins disabled except those essential to basic functionality.
- #A1, #A2, #A3
- Heading CSS looks fine to me, may have been fixed since this report was written.
- #B1, #B2, #B3
- require (complex) changes to the 3rd party Javascript used for sorting
- #C1, #C2
- When TablePlugin is disabled, and EditRowPlugin is enabled, the heading appears at the top of the table, and the table heading sort correctly when clicked.
- When TablePlugin is enabled, and EditRowPlugin is disabled, the table appears sorted as per the TABLE macro spec and clicking the header sorts correctly.
- When TablePlugin is enabled, and EditRowPlugin is enabled, the table appears as described.
- Since EditRowPlugin plays no part in sorting, it must be something that ERP is doing to cause TablePlugin to get the sort wrong. Observing that adding a
headerrows="1"
parameter to the TABLE macro suggests that the TablePlugin is unable to work out header rows when that parameter is not specified. It handles this by examining the header columns and if they are all surrounded by *, decides it's a header row. This is so crude, it makes me weep. Can be fixed by recognising an ERP generated header row.
- #D1
- the table is in fact sorted - by the first column. Since this is now an edit icon, the sort doesn't perform as expected. The TablePlugin has to understand the concept of pseudo-columns.
--
CrawfordCurrie - 19 Mar 2015
I have made extensive changes and improvements in the last few days. If you can give it another go, I'd be grateful!
--
CrawfordCurrie - 30 Mar 2015
Thanks Crawford, the problems I reported are longer there as far as I can see in my tests. Please note though the following
other issues introduced in your changes.
You can see them in action in
http://trunk.foswiki.org/Sandbox/TestNatEditWithTables (current rev 7), and I describe them hereafter.
if you use a plain TML table, when you click on a header of an unsorted table (as in cases B above):
- [E1]: the table gets sorted "up" instead of "down", which was the standard prior behaviour. i.e.: in reverse alphabetical order, if the contents are letters. This is a bit un-natural.
- [E2]: when a table is sorted after clicking on the header, an indicator icon shows for the sorting direction (a new indicator icon, inside a circle), but the symbol is reversed. The symbol
^
should be used when sorting is down (i.e. ascending from smaller to bigger), and the symbol v
when sorting is up (i.e. descending from bigger to smaller). Again, this was the previous behaviour.
- [E3]: hovering the mouse on the circled indicator icon for the sorting direction does not show a label confirming the sorting direction. This was the previous behaviour.
if you use %TABLE{initsort="1" initdirection="down"}%
According to the documentation in
http://foswiki.org/Extensions/TablePlugin "initdirection" sets the
Initial sorting direction for initsort, set to "up" (descending, or decreasing in value) or "down" (ascending, or increasing in value)
. So "down" means "ascending".
- [F1]: the icon shown is the old icon, and a correct label shows when hovering the mouse, but when you click the header to reverse the sorting direction, the circled indicator replaces it, and with a wrong sorting direction, and no label. Since a new circled indicator is used, it should be used consistently, whether the table is initially sorted or not. In this use case, the problems #E2 and #E3 also appear
if you use %TABLE{initsort="1" initdirection="down"}% and %EDITTABLE{}% (down means ascending)
- [G1]: two sorting indicator icons appear: the "old" one and the "new" (circled) one. Both indicators appear in the correct direction
^
for a "down" direction but only the "old" one has a label. Only one indicator should appear. Since the new circled indicator is used, it should be the only one appearing.
- [G2]: if you click on the header to reverse the sorting direction
- the "old" icon disappears, and the "new" circled one only appears, pointing to a reverse
v
- no sorting change is performed though, you need to click again for the sorting to change direction
- problems #E2 and #E3 also appear
if you use %TABLE{initsort="1" initdirection="up"}% and %EDITTABLE{}% (up means descending)
- [G3]: two sorting indicator icons appear: the "old" one and the "new" (circled) one. The old indicator appears in the correct direction
v
for a "up" direction, but the new circled one appears erroneously as ^
- [G4]: if you click on the header to reverse the sorting direction
- the "old" icon disappears, and the "new" circled one only appears, pointing erroneously to
v
- this time, the sorting change is performed on the rows without a need for 2 clicks
- problems #E2 and #E3 also appear
--
RaulFRodriguez - 07 Apr 2015
I beleiev they should all be good now.
--
CrawfordCurrie - 07 Apr 2015
Thanks Crawford
It looks good to me, except for this part of
#F1 which is still pending:
icon shown is the old icon (...) Since a new circled indicator is used, it should be used consistently
Also, I now see this one (not sure if it was there before or not):
- [G5]: in cases G (with EDITTABLE), the tooltip "Sort by this column" does not display on the sorted column's header (it does on the other column's headers).
--
RaulFRodriguez - 07 Apr 2015
F1 is not going to be fixed, as it requires a full replacement of
TablePlugin and I have to draw the line somewhere!
G5 I don't see - I'm missing your usual detail on how to reproduce this (and TBH I don't consider this Urgent so have downgraded the report to "Normal")
--
Main.CrawfordCurrie - 11 Apr 2015 - 05:59
Thanks Crawford, and sorry for the late reply.
About G5, see the live example there
http://trunk.foswiki.org/Sandbox/TestNatEditWithTables
- hovering the mouse on the sorted column header for "TML table with %TABLE{initsort="1" initdirection="down"}%" labelled "First Heading" shows a tooltip "Sort by this column"
- hovering the mouse on the sorted column header for "TML table with TML table with %TABLE{initsort="1" initdirection="down"}% and %EDITTABLE{}%" labelled "First Heading" does not show the tooltip (same if initdirection is "up", this is related to cases where EDITTABLE is used)
Agreed, this is not urgent given that the remaining issues are mostly cosmetic now.
There is a new inconsistency though, I just noticed, that did not seem to be there before, and which concerns any table after you click on a header for sorting it, or modifying the way it is sorted.
- [H1]: on any table, including plain TML, after a click on a table header, the wrong column header is highlighted, i.e. the darker background on the header signifying that this columns is the one being sorted is not set to the correct column, but to the column next to the sorted one. This capture example shows that the second column is sorted, but the darker background is on the 3rd:
--
RaulFRodriguez - 05 May 2015
Closing this. 2.0 is released. Need a new task to identify remaining issues.
--
GeorgeClark - 06 Jul 2015