| Possible bug in AbstractTable class [message #1823996] |
Mon, 06 April 2020 09:49  |
 Daniel Sanchez
Messages: 5
Registered: April 2019 |
Junior Member |
|
|
Hi everybody,
I would like to expose what I think is a possible bug, at least an undesirable behavior.
I have one Table class, that extends from AbstractTable, with several String Columns. Most part of the table is shown correctly, but there are some parts that are oddly shown.
If you sort that column in ascending order, you have the following:
(I'm only showing the part of the table that has the problem)
rowindex 63 --> Al P
rowindex 65 --> Al R
rowIndex 66 --> Al V
rowindex 56 --> Al-B
rowindex 57 --> Al-C
rowindex 64 --> Al-R
rowindex 67 --> Am
And now, if you sort in descending order you have the following:
rowindex 1309 --> Am
rowindex 1312 --> Al-R
rowindex 1319 --> Al-C
rowindex 1320 --> Al-B
rowindex 1310 --> Al V
rowindex 1311 --> Al R
rowindex 1313 --> Al P
As you can see, the rows are shown correctly, but the row indexes do not correspond with the logical order. There are no filters at all, and in the table are shown ALL the rows.
I have checked the rowindex and the filteredrowindex (just in case) and all of them are the same (rowindex == filteredrowindex)
Why the row indexes are not in order?
Thanks a lot in advance!
|
|
|
| Re: Possible bug in AbstractTable class [message #1824029 is a reply to message #1823996] |
Mon, 06 April 2020 17:40  |
|
Hi Daniel,
Yes, this is most likely a bug that is related to different collation behavior on the server and the browser.
As you may be aware, the classic Scout UI holds the actual model state in Java on the so-called "UI server". This state is synchronized with the runtime in the browser (written in JavaScript) by exchanging messages. To make the UI respond as fast as possible, it sometimes applies changes to the DOM directly without waiting for the UI server to respond. It is expected (and required) that both ends apply the same transformation to the model. In your case, the row order should be identical after applying the "sort" command to a column.
Unfortunately, sorting text is not as trivial as it sound. The letters A-Z are pretty easy, but where do you put special characters such as ä, é or ç? Sorting by ASCII code or unicode codepoint would be simple, but would not meet user expectations, because there are different rules for different languages. That's why sorting should be delegated to collators. Scout does that, but apparently the collator implementations in the browser and the JVM are not identical when it comes to the characters "-" (dash) and " " (space). You can verify this by sorting your table and then pressing Ctrl-R. This reloads the page and re-syncs the server-side model to the browser. You will find that some of your rows now have changed position.
Can you please file a bug? If possible, please include the browser model and version, the JVM version, your operating system and the server operating system and the locale.
Until this bug is fixed you can disable the faster UI sorting for that particular column by setting getConfiguredUiSortPossible() to false .
Regards,
Beat
|
|
|
|
Powered by
FUDForum. Page generated in 0.03064 seconds
] 
Search
Help
Register
Login
Home
