]
Nick Belaevski updated RF-8269:
-------------------------------
Fix Version/s: 4.0.0.ALPHA2
Assignee: Anton Belevich
problems with sorting API (i.e. ExtendedDataModel + Modifiable) that
goes with the rich:*dataTable components
-------------------------------------------------------------------------------------------------------------
Key: RF-8269
URL:
https://jira.jboss.org/jira/browse/RF-8269
Project: RichFaces
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: component-tables
Affects Versions: 3.3.2.SR1
Reporter: Ian Springer
Assignee: Anton Belevich
Fix For: 4.0.0.ALPHA2
Attachments: PagedDataModel.java
I recently tried to implement server-side sorting by implementing ExtendedDataModel +
Modifiable. I had several issues:
1) the name and usage of the Modifiable interface seem to assume that the sorting will be
done on the items from the currently loaded page of data (i.e. "modifying" that
in-memory list), but I think the more intuitive thing to do, particularly for large data
sets, is to sort the entire data set (e.g. using ORDER BY if the data set is stored in a
relational DB), and then return the appropriate page from the sorted data set.
2) when I click on a sortable column header, modify() is called several times. The first
few times, the original/previous values of the SortField2s are passed in, which serves no
purpose. modify() should be called exactly once per request, and the new sort fields and
filter fields should be passed in. Ideally, the same method would also support passing new
page range settings.
3) The order of the items in the List<SortField2> is not at all intuitive - it
appears to be as follows:
- The items in the list are ordered in reverse precedence (i.e. they are ordered from
the lowest priority fields to the highest priority fields, with the following exception:
If the last column clicked was already one of the sort fields (i.e. the user has
requested flipping that field from ASC->DESC or DESC-<ASC), the corresponding
SortField2 keeps its current position in the List, rather than being moved to the end of
the List, to signify it is now has the highest precedence (as it should, for consistency
sake)
It would be much more intuitive if the List was ordered by precedence, with the highest
priority fields first in the list, which is the same way sort fields are ordered in an
ORDER BY clause. Also, as described above, when toggling a column between ASC and DESC,
that column's should also be bumped up to the highest precedence. Filter fields should
also be ordered with the higher precedence filters first in the list, rather than last.
If I were to revamp the paging/sorting/filtering API, I'd make it look something like
the following and stick it right in the ExtendedDataModel interface:
void reloadData(List<FilterField> filterFields, List<SortField2> sortFields,
Range range)
This would allow the user of the API to load a new page of data with updated filtering,
sorting, and/or range in one swoop. The RF component impl would only call this method if
at least one of filterFields, sortFields, or range had been changed by the GUI user since
the last time reloadData() was called. It would also call the method exactly once per
request. This would save the implementer of the interface from having to cache the
previous values to track if any of them had actually changed or if reloadData() had
already been called for the current request.
I'm attaching the implementation of ExtendedDataModel + Modifiable that I did to
prototype using them for the Red Hat RHQ project. It shows the various ugly hacks I had to
do to make the API work. Based on the prototype, we have decided to stick with custom
components and facets we have been using, rather than using the sorting support currently
provided by rich:dataTable and rich:extendedDataTable. I hope the issues I've
described in this JIRA can be addressed, so we can switch over to using pure RichFaces.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: