[
https://jira.jboss.org/jira/browse/RF-8269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konstantin Mishin resolved RF-8269.
-----------------------------------
Resolution: Partially Completed
> 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: Konstantin Mishin
> 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:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
_______________________________________________
richfaces-issues mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/richfaces-issues
