Datatable: Sorters/Filters indexed by Column#field

Describe the defect As of today, sorters and filters are contained in a map indexed by clientId. Using LazyDataModel#load method, actives sorters/filters are transformed into a map where field is the key. At least two reasons for that:

• UIColumn#columnKey useless at this point
• Easy for the users to retrieve a specific sorter/filter from this map

If you take that sample #6421 in lazy mode, this will cause a problem since several columns are configured on the same field, basically you’ll end up with less sorters/filters than expected.

1st Solution An easy & quick solution would be to only filter active elements of that map, but key remain UIColumn#columnKey and you lose retrieving sorter/filter by field name. At this point, instead of using maps, lists could be passed as parameters to LazyDataModel#load method

2nd Solution Datatable no longer “authorized” having several columns with same field. Let’s take a more concrete example #5162, the user wants to display three columns “year”. It shows one significant enhancement to do, having a new filter constraint: range. But since it doesn’t exist, he created two additionnal columns from/to, and to identify them with UIColumn#field

As a reminder, UIColumn#field is only relevant when sorting or/and filtering is enabled. Having field as key would ease the impl of methods such as DataTable"updateSortByWithUserSortBy. It would also prevent bug when multiviewstate is enabled, and JSF tree is no longer the same when user comes back on that page (clientId will most likely change, and restoring table state would probably restore a wrong state for a column)

Let me know what you think 😉

[Rapster]

Does this sample actually work? I’m pretty sure it won’t in lazy mode

[tandraschko]

You’re only postponing the issue doing so, table component could change position in the JSF tree

Sure but thats another topic. Then we would need on each MultiViewStateAware-component a attr called “mvsKey” instead of the clientId.

It’s not an easy problem to solve as long as columnKey is based on a “volatile” value

users can simple set id=“brand” e.g., its the same as you would index by #field but more flexible.