[richfaces-issues] [JBoss JIRA] Commented: (RF-8269) problems with sorting API (i.e. ExtendedDataModel + Modifiable) that goes with the rich:*dataTable components

[Jay Balunas (JIRA)]

    [ https://jira.jboss.org/jira/browse/RF-8269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12509129#action_12509129 ] 

Jay Balunas commented on RF-8269:
---------------------------------

Thanks for the ideas and comments - we are discussing this and other iteration component changes here - http://community.jboss.org/message/521414

> 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: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira