[Engine-devel] Sorting in tabs

Thu Jun 27 15:15:29 UTC 2013

> ----- Original Message -----
> From: "Lior Vernia" <lvernia at redhat.com>
> Sent: Thursday, June 27, 2013 10:38:04 AM
> 
> 
> 
> On 27/06/13 16:42, Einav Cohen wrote:
> >> ----- Original Message -----
> >> From: "Lior Vernia" <lvernia at redhat.com>
> >> Sent: Thursday, June 27, 2013 8:53:59 AM
> >>
> >>
> >>
> >> On 27/06/13 15:37, Einav Cohen wrote:
> >>>> ----- Original Message -----
> >>>> From: "Eli Mesika" <emesika at redhat.com>
> >>>> Sent: Thursday, June 27, 2013 6:46:58 AM
> >>>>
> >>>>
> >>>> ----- Original Message -----
> >>>>> From: "Lior Vernia" <lvernia at redhat.com>
> >>>>> To: engine-devel at ovirt.org
> >>>>> Sent: Thursday, June 27, 2013 10:12:33 AM
> >>>>> Subject: [Engine-devel] Sorting in tabs
> >>>>>
> >>>>> Hello everyone (UI peeps in particular),
> >>>>>
> >>>>> I've pushed (not yet merged) a patch that would enable us to keep items
> >>>>> in tabs (main/sub) sorted at all times by setting a comparator in
> >>>>> SearchableListModel:
> >>>>
> >>>> But tabs includes only 100 records and supports paging , how you deal
> >>>> with
> >>>> that ???
> >>>
> >>> if this is in the GUI level, then I assume that the comparator is simply
> >>> comparing the
> >>> items within the current page, and not "globally".
> >>> so the sorting doesn't affect the set of items that is displayed in the
> >>> page (it would
> >>> be the same as before the sorting) - just their order.
> >>
> >> Yes, if I understand correctly how the paging works, Einav is correct -
> >> only the items passed to the UI are sorted.
> >>
> >>> also: @Lior - what happens when the search query contains a "sort by"
> >>> part?
> >>> there is a chance that the behaivor would be unexpected in this case;
> >>
> >> Yes, I thought about this case, and it may result in a confusing user
> >> experience if developers aren't careful. Together with the issue of
> >> paging, this probably makes this sorting mechanism a better candidate
> >> for use within subtabs rather than main tabs.
> > 
> > note that at some point, I think that we would want to introduce paging
> > also to search-
> > based sub-tabs - it will be useful especially for sub-tabs that potentially
> > display a
> > large number of results (e.g. Disks sub-tab in Storage main tab).
> > In addition, at some point, we would want to get rid of the paging UI as it
> > is now
> > (i.e. "next"/"prev" buttons at the top panel) and move to paging triggered
> > by scroll
> > (i.e. have a very long grid, dynamically loaded as you continue to scroll -
> > similar
> > to the behavior of some e-mail web-clients, for example). In this case,
> > sorting on
> > the client side will make no sense at all (i.e. from the user perspective,
> > only a
> > portion of a very large grid will be sorted, the other portions won't be).
> > 
> > So for now - yes, I think it makes sense to introduce your mechanism to all
> > sub-tabs,
> > however in the long-term - we would probably want the search-based sub-tabs
> > (which
> > will support paging) to move to search-based sorting, rather than
> > GUI-based-sorting.
> 
> Sounds good to me. Let me just re-iterate that it is not mandatory to
> set a comparator, so in technical terms it's not even necessary to
> introduce it at once to all sub-tabs, if they're already sorting their
> items some other way. It could happen gradually, and only if developers
> find it more convenient. In either case, dropping the GUI sorting once
> search-based sorting is implemented shouldn't be difficult.
> 
> > BTW (maybe the other GUI maintainers can help me with that one) - what
> > about sub-tabs
> > that are not search-based (i.e. display results from a "regular" query or
> > even from a
> > field within the selected item in the main grid, e.g. Applications in VM) -
> > are these
> > managed via SearchableListModel as well? since the comparator mechanism
> > *is* relevant
> > for them.
> 
> As far as I've seen, some are managed via SearchableListModel and some
> aren't. Those that aren't are those that display non-trivial behaviour
> upon receipt of the items to display (setItems() method) - often this
> non-trivial behaviour is exactly sorting :) And if it's doing its job,
> then there's no necessity to change it either. But anyway, I don't know
> all of them, so I'd also love to hear GUI maintainers.
> 
> > Also: Worth mentioning "Bug 893999 - webadmin: please allow column
> > sorting", which
> > requests to enable sorting when clicking on a grid-column header; when
> > implementing
> > column-sorting, probably worth attaching your mechanism to it somehow (i.e.
> > clicking on
> > a column header should set the relevant comparator in the relevant
> > SearchableListModel).
> 
> I didn't want to say it, because if we upgrade to a newer version of GWT
> then we could probably use their table column sorting. But this
> mechanism could allow us to achieve this without upgrading, and it was
> definitely sitting in the back of my head when I implemented it. All
> that's needed is, as you said, to listen to table header clicks in the
> view, and then appropriately set the comparator in the model.
> 

[Vojtech/GUI-maintainers - your input would be appreciated here]

we are actually planning on upgrading the GWT version *really* soon (to GWT 2.5), 
so my question is: should we wait until the new GWT is introduced, and implement 
client-sorting based on the GWT-grid-widget built-in mechanism (assuming there is 
one)?
also, not sure if it is better to utilize the widget default-built-in sorting mechanism 
(which doesn't manipulate the uicommon model data at all), or if it is better to utilize 
your comparator mechanism, which manipulates the uicommon model data, and the GUI-widget 
just reflects this data at any given time. 
thoughts?

> >>
> >>>
> >>> I believe that the correct thing to do is to "attach" the GUI sorting
> >>> mechanism
> >>> to the one in the search mechanism.
> >>>
> >>> thoughts?
> >>
> >> This can be done, however I'm not sure there's much utility in it. Main
> >> tabs are always sorted according to some default ordering even if one
> >> was not entered in the search panel, and this sorting is also performed
> >> consistently with respect to paging. So maybe the right thing to do
> >> would be to just "block" the GUI sorting mechanism for main tabs (i.e.
> >> override the setter method and make it no-op)?
> > 
> > yes, and related to what I mentioned above - at some point in the future,
> > we'd might want
> > to block it for search-based sub-tabs as well.
> > 
> >>
> >>>>
> >>>>
> >>>>>
> >>>>> http://gerrit.ovirt.org/#/c/15846/
> >>>>>
> >>>>> If a comparator isn't set, then everything should behave as before. If
> >>>>> a
> >>>>> comparator is set, then from that moment on the tab items will be kept
> >>>>> in a SortedSet, so that even if an item is added in a way that doesn't
> >>>>> trigger an event (e.g. getItems().add()) the items will be kept sorted
> >>>>> according to the given comparator. If the comparator is set to null,
> >>>>> from that moment on the tab should revert to its old behaviour.
> >>>>>
> >>>>> You're most welcome to have a look and let me know if this might break
> >>>>> something (remember though that it's not obligatory to set a
> >>>>> comparator,
> >>>>> so only possible breakage should be in generic flows).
> >>>>>
> >>>>> Feel free to use it once it's merged; along with SortedListModel, this
> >>>>> should make sorting less painful. Just keep in mind that once you set a
> >>>>> comparator, you can't cast getItems() to a List. This shouldn't be a
> >>>>> problem in general, as mostly it's as useful (and probably more
> >>>>> correct)
> >>>>> to cast to a Collection.
> >>>>>
> >>>>> Lior.
> >>>>> _______________________________________________
> >>>>> Engine-devel mailing list
> >>>>> Engine-devel at ovirt.org
> >>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> >>>>>
> >>>> _______________________________________________
> >>>> Engine-devel mailing list
> >>>> Engine-devel at ovirt.org
> >>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> >>>>
> >>
> 