Vojtech Szocs has posted comments on this change. Change subject: webadmin: Support column sorting ......................................................................
Patch Set 3: (1 comment) Daniel, thanks for your comment! Please have a look at my follow-up comment and let me know what you think. http://gerrit.ovirt.org/#/c/25910/3/frontend/webadmin/modules/webadmin/src/main/java/org/ovirt/engine/ui/webadmin/section/main/view/tab/datacenter/SubTabDataCenterClusterView.java File frontend/webadmin/modules/webadmin/src/main/java/org/ovirt/engine/ui/webadmin/section/main/view/tab/datacenter/SubTabDataCenterClusterView.java: Line 34: } Line 35: }; Line 36: nameColumn.makeSortable(new Comparator<VDSGroup>() { Line 37: @Override Line 38: public int compare(VDSGroup a, VDSGroup b) { > * Can we add to the infrastructure some flag/mechanism for indicating wheth > Can we add to the infrastructure some flag/mechanism for indicating whether > the list should be sorted ascending or descending - as for this example, > sorting is not functional since the comperator's order is constant... Excellent point! I completely forgot about this in my implementation. I'll modify AbstractActionTable.initSortHandler method to set sort order in case of using client-side Comparator, for example: Comparator<? super T> comparator = ... searchableModel.setComparatorAscending(trueOrFalse); searchableModel.setComparator(comparator); In SearchableListModel.setComparator method, we can check "comparatorAscending" flag and wrap passed Comparator into one that takes this flag into account, for example: Comparator<T> sortOrderSensitiveComparator = new Comparator<T>() { @Override public int compare(T a, T b) { int ascResult = comparator.compare(a, b); return comparatorAscending ? ascResult : -ascResult; } }; Client code therefore doesn't need to worry about sort order, it just passes one (ascending order) Comparator to SortableColumn.makeSortable method and infrastructure takes care of the rest. > Just a note for after merging the infrastructure - we probably should reuse > comparators from Linq class or some other helper. +1 If we already have some Comparators defined, we should attempt to reuse them if possible. Line 39: if (a == b) { Line 40: return 0; Line 41: } else if (a == null) { Line 42: return -1; -- To view, visit http://gerrit.ovirt.org/25910 To unsubscribe, visit http://gerrit.ovirt.org/settings Gerrit-MessageType: comment Gerrit-Change-Id: I141ea068fe90409852d34bea6fedb45d0d8a07ae Gerrit-PatchSet: 3 Gerrit-Project: ovirt-engine Gerrit-Branch: master Gerrit-Owner: Vojtech Szocs <vsz...@redhat.com> Gerrit-Reviewer: Alexander Wels <aw...@redhat.com> Gerrit-Reviewer: Daniel Erez <de...@redhat.com> Gerrit-Reviewer: Einav Cohen <eco...@redhat.com> Gerrit-Reviewer: Gilad Chaplik <gchap...@redhat.com> Gerrit-Reviewer: Greg Sheremeta <gsher...@redhat.com> Gerrit-Reviewer: Lior Vernia <lver...@redhat.com> Gerrit-Reviewer: Tomas Jelinek <tjeli...@redhat.com> Gerrit-Reviewer: Vojtech Szocs <vsz...@redhat.com> Gerrit-Reviewer: automat...@ovirt.org Gerrit-Reviewer: oVirt Jenkins CI Server Gerrit-HasComments: Yes _______________________________________________ Engine-patches mailing list Engine-patches@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-patches