Review Request: Add client-side sorting and filtering to queue tables
Henry Andrews
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.comics.org/r/954/
-----------------------------------------------------------
Review request for GGD Tech Group.
Summary
-------
Hi folks,
I'm not up on the current state of trunk and the release plans, and this is pretty much out of left field, so consider this review a proposal for consideration rather than something I expect to go in right now in this exact form.
I recently encountered the datatables jQuery plugin. It is awesome. There are a few other rich-table libraries out there, but this one most closely matches in philosophy what we actually have- straightforward tables of data. You can get a good feel for it using the live demos on its site: http://datatables.net/ (the Examples section is pretty obvious, most of the docs are hiding in the Usage section. The full reference is at http://datatables.net/ref with slightly more verbose pages elsewhere under the Usage or API headings- mostly Usage).
I started looking at it with the intention of applying it to search results, but that gets a little bit complicated with the server-side interactions. Not very complicated, but given the way our current search performs, there are some subtleties to consider. Looking around, I realized that the queue pages were the ideal first testing ground. They have a relatively limited audience, and they load entirely up front, without pagination. And they suck to work with when the tables are big, because there's no sorting or filtering available at all. Also, this only took a few hours to do do, including lots of comparing options and testing different browsers.
This puts a very basic datatables instance on the editing, pending and reviewing queues, as well as the agenda and voting tables (all of which were already implemented with the queue table code). I left the covers queue alone (it's not the same sort of table, although we may be able to use datatables with it given some thought) as well as the approved page (it's paginated, so back to server-side interaction there).
The search filter searches dynamically across the entire table contents. There are many ways to get fancy with that, including per-column searches, but after some experimentation, this seems like the most usable option. It is certainly the most intuitive with the least number of clicks and keystrokes.
Sorting works by clicking any heading (perhaps they should be styled to look more clickable?). Shift-clicking does multiple levels of sort (up to three, I think), but I currently don't render the arrows differently for the different levels. We could. The "arrows", btw, are just ^ and v characters because I didn't want to mess with icons for the proof of concept. Presumably if we go with this we'll add real icons. There is a bit of a wrinkle with getting the media path into the css files that I didn't want to deal with right now either.
I considered setting an initial sort, because by default it just sorts by the first column (imp count for the changeset queues), which throws away the server-side sorting. However, the tables also remember your last sort and filter so once you start clicking around, the default sort is kind of irrelevant. I figured it better to get feedback on that. We may want to drop the server-side sorting if it improves performance.
I also have the entire DataTables-1.8.2 tree svn added as media/DataTables-1.8.2 (perhaps it should just be media/DataTables for upgrade sanity?). Note that it comes with its own copy of jQuery (which is just a standard unmodified jQuery, but much more recent than what we're using elsewhere). If folks want to see a code review of it, I can post it separately, but there are quite a few files and it's stock 3rd-party code. I don't know if we even want to check it in vs just installing it on production.
Diffs
-----
/pydjango/media/css/oi/default/queues.css 1332
/pydjango/media/js/oi/queuetables.js PRE-CREATION
/pydjango/templates/gcd/base.html 1332
/pydjango/templates/oi/bits/standard_queues.html 1332
/pydjango/templates/oi/queues/editing.html 1332
/pydjango/templates/oi/queues/pending.html 1332
/pydjango/templates/oi/queues/queue_base.html PRE-CREATION
/pydjango/templates/oi/queues/reviews.html 1332
/pydjango/templates/voting/agenda.html 1332
/pydjango/templates/voting/base_view.html 1332
/pydjango/templates/voting/dashboard.html 1332
Diff: http://reviews.comics.org/r/954/diff
Testing
-------
Mac OS X: Chrome and Safari
Windows: Firefox, IE 6 through 9
IE 6 and IE 7 don't show the sort arrows, as they don't support the :before CSS pseudo-element selector. IE 7 has some problem with the table borders (see screenshot). IE 7 seems to have problems in general- how much do we care?
Chrome, Safari and Firefox are the latest versions of each as everything self-updates aggressively these days.
Screenshots
-----------
Chrome (Mac OS X) Agenda
http://reviews.comics.org/r/954/s/216/
Firefox (Windows) Editing
http://reviews.comics.org/r/954/s/217/
IE9 Pending
http://reviews.comics.org/r/954/s/218/
IE8 Pending
http://reviews.comics.org/r/954/s/219/
IE7 Pending
http://reviews.comics.org/r/954/s/220/
Thanks,
Henry
Jochen G.
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
-----------------------------------------------------------
Thanks for tackling this. Will take a bit before I can take a closer look at it.
Just one question out of curiosity, did you have a look at one of the django packages for table sorting (django-tables2, I think there is at least another one)
- Jochen
On 2011-11-27 15:37:00, Henry Andrews wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.comics.org/r/954/
> -----------------------------------------------------------
>
> (Updated 2011-11-27 15:37:00)
Jochen G.
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
-----------------------------------------------------------
Thanks for tackling this. Will take a bit before I can take a closer look at it.
Just one question out of curiosity, did you have a look at one of the django packages for table sorting (django-tables2, I think there is at least another one)
- Jochen
On 2011-11-27 15:37:00, Henry Andrews wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.comics.org/r/954/
> -----------------------------------------------------------
>
> (Updated 2011-11-27 15:37:00)
>
>
Issac Kelly
Issac
> --
> GCD-Tech mailing list - gcd-...@googlegroups.com
> To unsubscribe send email to gcd-tech+u...@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/gcd-tech
Henry Andrews
> On 2011-11-27 18:17:05, Jochen G. wrote:
> > Thanks for tackling this. Will take a bit before I can take a closer look at it.
> >
> > Just one question out of curiosity, did you have a look at one of the django packages for table sorting (django-tables2, I think there is at least another one)
No. I saw you mention it in reply to the introduction of a new list member, and very briefly glanced at it, but I already had datatables up and running. The advantage of datatables is that you can attach it to any sort of table. It will connect to the back end, or (as here) apply to a pre-populated table.
Taking a closer look at django-tables2 just now, it appears to be entirely server-side. I believe it would be possible to use django-tables2 for the back-end of a datatables instance that hooks to server-side processing. Although they might have some clashes about pagination and sorting. So far, it's been so easy to set up a datatable source on the server side that I haven't wanted to look for anything to further automate it. There is a django-datatables package of some sort but it didn't really add anything that seemed useful to me (IIRC it only addressed the simplest form of server-side integration, which won't work for us, at least not for large sets of search results).
Finally, for the search stuff, we're going to want to back-end the datatable to a haystack.query.SearchQuerySet object rather than a traditional Django model queryset. That puts us in a somewhat different problem space than what django-tables2 is trying to solve.
- Henry
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.comics.org/r/954/#review2053
-----------------------------------------------------------
Henry Andrews
From: Issac Kelly <issac...@gmail.com>
To: "gcd-...@googlegroups.com" <gcd-...@googlegroups.com>
Sent: Sunday, November 27, 2011 10:23 AM
Subject: Re: [gcd-tech] Re: Review Request: Add client-side sorting and filtering to queue tables
> To unsubscribe send email to gcd-tech+unsub...@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/gcd-tech
--
GCD-Tech mailing list - gcd-...@googlegroups.com
To unsubscribe send email to gcd-tech+unsub...@googlegroups.com
Henry Andrews
From: Henry Andrews <hh...@cornell.edu>
To: "gcd-...@googlegroups.com" <gcd-...@googlegroups.com>
Sent: Sunday, November 27, 2011 10:31 AM
To unsubscribe send email to gcd-tech+u...@googlegroups.com
Issac Kelly
I prefer server side approaches for this, primarily so that urls can
be passed around or bookmarked easier.
Issac
Jochen G.
> On 2011-11-27 18:17:05, Jochen G. wrote:
> > Thanks for tackling this. Will take a bit before I can take a closer look at it.
> >
> > Just one question out of curiosity, did you have a look at one of the django packages for table sorting (django-tables2, I think there is at least another one)
>
> Henry Andrews wrote:
> No. I saw you mention it in reply to the introduction of a new list member, and very briefly glanced at it, but I already had datatables up and running. The advantage of datatables is that you can attach it to any sort of table. It will connect to the back end, or (as here) apply to a pre-populated table.
>
> Taking a closer look at django-tables2 just now, it appears to be entirely server-side. I believe it would be possible to use django-tables2 for the back-end of a datatables instance that hooks to server-side processing. Although they might have some clashes about pagination and sorting. So far, it's been so easy to set up a datatable source on the server side that I haven't wanted to look for anything to further automate it. There is a django-datatables package of some sort but it didn't really add anything that seemed useful to me (IIRC it only addressed the simplest form of server-side integration, which won't work for us, at least not for large sets of search results).
>
> Finally, for the search stuff, we're going to want to back-end the datatable to a haystack.query.SearchQuerySet object rather than a traditional Django model queryset. That puts us in a somewhat different problem space than what django-tables2 is trying to solve.
django-tables2 has a bullet point in regard to haystack:
Added support for using django-haystack's SearchQuerySet as a data source
I'll try to have a closer look in the next couple of days.
I guess a major point to consider for later (i.e. search result pages, not the queues like here) is in regard to pagination.
- Jochen
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.comics.org/r/954/#review2053
-----------------------------------------------------------
Henry Andrews
Sent: Sunday, November 27, 2011 10:31 AM
Subject: Re: [gcd-tech] Re: Review Request: Add client-side sorting and filtering to queue tables
> To unsubscribe send email to gcd-tech+unsub...@googlegroups.com
Henry Andrews
Sent: Sunday, November 27, 2011 11:03 AM
To unsubscribe send email to gcd-tech+u...@googlegroups.com
Issac Kelly
Issac
Henry Andrews
Sent: Sunday, November 27, 2011 11:08 AM
Jochen G.
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
-----------------------------------------------------------
Codewise this looks fine, but at this stage I am reluctant to say ship it since this concerns other issues we need to address, besides you call it proof of concept for a reason...
We could put this via a diff on beta to get some feedback from others and see how useful they find it.
For procedure in regard to the external code, I think that these should not be in the svn, although we have added some small bits of js so far. I haven't looked into the backward compability of jquery, i.e. how much we would have to worry that something breaks if we just say 'jquery, current version' instead of picking the code blocks we are using. In this case it seems we need the full jquery ?
- Jochen
On 2011-11-27 15:37:00, Henry Andrews wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.comics.org/r/954/
> -----------------------------------------------------------
>
> (Updated 2011-11-27 15:37:00)
>
>
Henry Andrews
> On 2011-12-06 23:55:15, Jochen G. wrote:
> > Codewise this looks fine, but at this stage I am reluctant to say ship it since this concerns other issues we need to address, besides you call it proof of concept for a reason...
> >
> > We could put this via a diff on beta to get some feedback from others and see how useful they find it.
> >
> > For procedure in regard to the external code, I think that these should not be in the svn, although we have added some small bits of js so far. I haven't looked into the backward compability of jquery, i.e. how much we would have to worry that something breaks if we just say 'jquery, current version' instead of picking the code blocks we are using. In this case it seems we need the full jquery ?
I would like to see this on beta to get feedback, as there's no way to proceed without feedback.
What are the "other issues we need to address"? This doesn't have anything to do with the client-side vs server-side tables question, as these tables are loaded fully from the server in a single request.
I'm not sure about what you mean by "full jquery". jquery is a single thing. There are many plugins and extensions, but underneath, there's just jquery.
- Henry
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.comics.org/r/954/#review2067
-----------------------------------------------------------
Henry Andrews
> On 2011-12-06 23:55:15, Jochen G. wrote:
> > Codewise this looks fine, but at this stage I am reluctant to say ship it since this concerns other issues we need to address, besides you call it proof of concept for a reason...
> >
> > We could put this via a diff on beta to get some feedback from others and see how useful they find it.
> >
> > For procedure in regard to the external code, I think that these should not be in the svn, although we have added some small bits of js so far. I haven't looked into the backward compability of jquery, i.e. how much we would have to worry that something breaks if we just say 'jquery, current version' instead of picking the code blocks we are using. In this case it seems we need the full jquery ?
>
> Henry Andrews wrote:
> I would like to see this on beta to get feedback, as there's no way to proceed without feedback.
>
> What are the "other issues we need to address"? This doesn't have anything to do with the client-side vs server-side tables question, as these tables are loaded fully from the server in a single request.
>
> I'm not sure about what you mean by "full jquery". jquery is a single thing. There are many plugins and extensions, but underneath, there's just jquery.
>
Sorry, I can see now why you might be confused about "the full jQuery". DataTables includes a recent version of jquery within its distribution for compatibility. You can use a different one if it's recent enough (but the one that we have checked in is not- it is quiet old).
I've gone ahead and deployed this with a patch. I verified that none of the files that were patched were already modified, so reverting it will be easy. I will solicit feedback on gcd-main.
- Henry
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.comics.org/r/954/#review2067
-----------------------------------------------------------
Jochen G.
> On 2011-12-06 23:55:15, Jochen G. wrote:
> > Codewise this looks fine, but at this stage I am reluctant to say ship it since this concerns other issues we need to address, besides you call it proof of concept for a reason...
> >
> > We could put this via a diff on beta to get some feedback from others and see how useful they find it.
> >
> > For procedure in regard to the external code, I think that these should not be in the svn, although we have added some small bits of js so far. I haven't looked into the backward compability of jquery, i.e. how much we would have to worry that something breaks if we just say 'jquery, current version' instead of picking the code blocks we are using. In this case it seems we need the full jquery ?
>
> Henry Andrews wrote:
> I would like to see this on beta to get feedback, as there's no way to proceed without feedback.
>
> What are the "other issues we need to address"? This doesn't have anything to do with the client-side vs server-side tables question, as these tables are loaded fully from the server in a single request.
>
> I'm not sure about what you mean by "full jquery". jquery is a single thing. There are many plugins and extensions, but underneath, there's just jquery.
>
>
> Henry Andrews wrote:
> Sorry, I can see now why you might be confused about "the full jQuery". DataTables includes a recent version of jquery within its distribution for compatibility. You can use a different one if it's recent enough (but the one that we have checked in is not- it is quiet old).
>
> I've gone ahead and deployed this with a patch. I verified that none of the files that were patched were already modified, so reverting it will be easy. I will solicit feedback on gcd-main.
>
re: jquery, sorry I was confused, I thought we only had a subset of jquery checked in, but it is the full one.
The 'other issues' does concern the consideration for search results where we need to deal with pagination. We shouldn't use one table sorting solution if it cannot be used in other situations. It might be that we can and will use this one, but I need to look more into it. Btw, at some point I did a local proof of concept with one of the django ways of table sorting, I'll try to see if I can reactivate that.
On behaviour, I think the default should be the same as the current server side setting and that there should be a button, or some other way, to reset to the default one.
- Jochen
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.comics.org/r/954/#review2067
-----------------------------------------------------------
Henry Andrews
> On 2011-12-06 23:55:15, Jochen G. wrote:
> > Codewise this looks fine, but at this stage I am reluctant to say ship it since this concerns other issues we need to address, besides you call it proof of concept for a reason...
> >
> > We could put this via a diff on beta to get some feedback from others and see how useful they find it.
> >
> > For procedure in regard to the external code, I think that these should not be in the svn, although we have added some small bits of js so far. I haven't looked into the backward compability of jquery, i.e. how much we would have to worry that something breaks if we just say 'jquery, current version' instead of picking the code blocks we are using. In this case it seems we need the full jquery ?
>
> Henry Andrews wrote:
> I would like to see this on beta to get feedback, as there's no way to proceed without feedback.
>
> What are the "other issues we need to address"? This doesn't have anything to do with the client-side vs server-side tables question, as these tables are loaded fully from the server in a single request.
>
> I'm not sure about what you mean by "full jquery". jquery is a single thing. There are many plugins and extensions, but underneath, there's just jquery.
>
>
> Henry Andrews wrote:
> Sorry, I can see now why you might be confused about "the full jQuery". DataTables includes a recent version of jquery within its distribution for compatibility. You can use a different one if it's recent enough (but the one that we have checked in is not- it is quiet old).
>
> I've gone ahead and deployed this with a patch. I verified that none of the files that were patched were already modified, so reverting it will be easy. I will solicit feedback on gcd-main.
>
>
> Jochen G. wrote:
> re: jquery, sorry I was confused, I thought we only had a subset of jquery checked in, but it is the full one.
>
> The 'other issues' does concern the consideration for search results where we need to deal with pagination. We shouldn't use one table sorting solution if it cannot be used in other situations. It might be that we can and will use this one, but I need to look more into it. Btw, at some point I did a local proof of concept with one of the django ways of table sorting, I'll try to see if I can reactivate that.
>
> On behaviour, I think the default should be the same as the current server side setting and that there should be a button, or some other way, to reset to the default one.
I don't agree that we need the same table sorting solution everywhere. Not all of our current tables are the same. They don't all behave the same and they don't all have the same audience. We should not have tables that serve the same purpose behaving differently, but tables that serve different purposes should behave in the ways that most suit those purposes.
In particular, there's no reason to slow down a table with server-side processing (and increase the server load) when it has all of its data on the client side already. Why would you bookmark the queue tables in any particular state? The client-side code remembers your last sorting and filtering anyway.
Additionally, some problems are cheaper to fix than others. Why not fix some cheap ones now?
- Henry
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.comics.org/r/954/#review2067
-----------------------------------------------------------
Jochen G.
> On 2011-12-06 23:55:15, Jochen G. wrote:
> > Codewise this looks fine, but at this stage I am reluctant to say ship it since this concerns other issues we need to address, besides you call it proof of concept for a reason...
> >
> > We could put this via a diff on beta to get some feedback from others and see how useful they find it.
> >
> > For procedure in regard to the external code, I think that these should not be in the svn, although we have added some small bits of js so far. I haven't looked into the backward compability of jquery, i.e. how much we would have to worry that something breaks if we just say 'jquery, current version' instead of picking the code blocks we are using. In this case it seems we need the full jquery ?
>
> Henry Andrews wrote:
> I would like to see this on beta to get feedback, as there's no way to proceed without feedback.
>
> What are the "other issues we need to address"? This doesn't have anything to do with the client-side vs server-side tables question, as these tables are loaded fully from the server in a single request.
>
> I'm not sure about what you mean by "full jquery". jquery is a single thing. There are many plugins and extensions, but underneath, there's just jquery.
>
>
> Henry Andrews wrote:
> Sorry, I can see now why you might be confused about "the full jQuery". DataTables includes a recent version of jquery within its distribution for compatibility. You can use a different one if it's recent enough (but the one that we have checked in is not- it is quiet old).
>
> I've gone ahead and deployed this with a patch. I verified that none of the files that were patched were already modified, so reverting it will be easy. I will solicit feedback on gcd-main.
>
>
> Jochen G. wrote:
> re: jquery, sorry I was confused, I thought we only had a subset of jquery checked in, but it is the full one.
>
> The 'other issues' does concern the consideration for search results where we need to deal with pagination. We shouldn't use one table sorting solution if it cannot be used in other situations. It might be that we can and will use this one, but I need to look more into it. Btw, at some point I did a local proof of concept with one of the django ways of table sorting, I'll try to see if I can reactivate that.
>
> On behaviour, I think the default should be the same as the current server side setting and that there should be a button, or some other way, to reset to the default one.
>
> Henry Andrews wrote:
> I don't agree that we need the same table sorting solution everywhere. Not all of our current tables are the same. They don't all behave the same and they don't all have the same audience. We should not have tables that serve the same purpose behaving differently, but tables that serve different purposes should behave in the ways that most suit those purposes.
>
> In particular, there's no reason to slow down a table with server-side processing (and increase the server load) when it has all of its data on the client side already. Why would you bookmark the queue tables in any particular state? The client-side code remembers your last sorting and filtering anyway.
>
> Additionally, some problems are cheaper to fix than others. Why not fix some cheap ones now?
Sure, we don't need to have the same solution for table sorting everywhere, but it would be preferable if we can use the same technology in more then one place. And before I have an opinion on that I need to have a closer look at the other possibilities. And tables are tables, if we make a decision to have them behave differently in their interactive sorting it should be a conscious decision and not because we have an easy and cheap fix for one situation. In any case, this seems quite useable, with some needed modifications.
- Jochen
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.comics.org/r/954/#review2067
-----------------------------------------------------------
Jochen G.
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
-----------------------------------------------------------
Looked a bit more into other django options, but (not surprisingly) these don't handle client side sorting. So this could be used when we can do client-side sorting. For search results this seems problematic because the results can be large, so there we would need server side sorting and pagination. Only for search results with less than, say, 100, results we can use the client-side sorting, so mid-term we need to combine these. Which implies the look and feel should be mostly the same, no matter what solution we use in each case. Or can datatables be used with server-side sorting as well, for cases when the results table would be too large ?
One thing we have to think about at one stage is multiple column sorting, here with JavaScript it goes via shift-click. Although I wonder if the average web-user would know to do that (from the few reponses the list: 1 yes / 1 no / 1 didn't mention it) ? Anyway, with a django solution a shift click wouldn't be possible I assume. Does datatables offer alternatives to the shift-click ? Would be moot if we can use (see above) datatables always in the display part.
On the list it was mentioned that the headers should display as links, I kind of disagree, since they are not links in the real sense. The 'I am clickable' aspect would come by corresponding arrows, either like django-tables2 https://github.com/bradleyayers/django-tables2 with colored/uncolored arrows, or like on the datables example page where three types of arrows are shown, or something like that.
Behaviour wise, I think the current sort behaviour of the pending queue is the most reasonable, changeset with the oldest status change (and which are in pending) on top. That way they are less easy to ignore. Having always one owns sorting makes 'cherry picking' of favourite indexers easier, which is something we shouldn't encourage, I think. There definitly (as also mentioned by Don) should be a way to easily resort to our default sorting. Maybe even fall back to this after a revisit of the page after a certain time, as in keep the sort order during a session, but not over sessions.
- Jochen
On 2011-11-27 15:37:00, Henry Andrews wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.comics.org/r/954/
> -----------------------------------------------------------
>
> (Updated 2011-11-27 15:37:00)
>
>
Henry Andrews
> On 2011-12-24 14:21:55, Jochen G. wrote:
> > Looked a bit more into other django options, but (not surprisingly) these don't handle client side sorting. So this could be used when we can do client-side sorting. For search results this seems problematic because the results can be large, so there we would need server side sorting and pagination. Only for search results with less than, say, 100, results we can use the client-side sorting, so mid-term we need to combine these. Which implies the look and feel should be mostly the same, no matter what solution we use in each case. Or can datatables be used with server-side sorting as well, for cases when the results table would be too large ?
> >
> > One thing we have to think about at one stage is multiple column sorting, here with JavaScript it goes via shift-click. Although I wonder if the average web-user would know to do that (from the few reponses the list: 1 yes / 1 no / 1 didn't mention it) ? Anyway, with a django solution a shift click wouldn't be possible I assume. Does datatables offer alternatives to the shift-click ? Would be moot if we can use (see above) datatables always in the display part.
> >
> > On the list it was mentioned that the headers should display as links, I kind of disagree, since they are not links in the real sense. The 'I am clickable' aspect would come by corresponding arrows, either like django-tables2 https://github.com/bradleyayers/django-tables2 with colored/uncolored arrows, or like on the datables example page where three types of arrows are shown, or something like that.
> >
> > Behaviour wise, I think the current sort behaviour of the pending queue is the most reasonable, changeset with the oldest status change (and which are in pending) on top. That way they are less easy to ignore. Having always one owns sorting makes 'cherry picking' of favourite indexers easier, which is something we shouldn't encourage, I think. There definitly (as also mentioned by Don) should be a way to easily resort to our default sorting. Maybe even fall back to this after a revisit of the page after a certain time, as in keep the sort order during a session, but not over sessions.
> >
> >
Thanks for the thorough evaluation, Jochen! datatables *can* be used with server-side sorting and pagination as well. It sends AJAX requests to the server to pull up each new page or re-sort the table. It's up to the server code to interpret the request and send a suitable response back with the right data to display. It may even be useful to use the django-tables2 package to generate the data for each request from datatables- I have not looked into that idea at all so far. The one drawback to the AJAX system, as the fellow who worked on django-tables2 mentioned, is that you cannot easily bookmark a particular table state. It's easy to arrange things to allow bookmarking the *initial* state of the table (i.e. of all items, unfiltered), but bookmarking, say, the 2nd page when filtered by publisher and then sorted by first date then title, would require adding a "bookmarkable link" button of some sort that reloaded the page with the right URL. Which also required adding a bit more JavaScript so that the table can be initialized in that paged/sorted/filtered state as well as on the first page. Whether there's a way to have a django-tables2 back end make that easier is not clear to me- I suspect datatables would control the entire front end in a hybrid system. I also suspect that bookmarking all of those different possible states is not a common use case, and an initial implementation that correctly bookmarks the search/filter parameters would be a useful starting point.
In order to use / restore our default sorting we just need to associate it with a column in some way. I'm a little vague on the details, but IIRC you can change the sorting behavior for a column so that instead of directly sorting on the text contents it runs some other function to determine the sort. And of course if you're sorting on the server side you can do whatever you want with it. I'm not certain what interface other than shift-click would be good for multi-column sorts- that's the one I've always seen. Datatables allows up to three, which is also a fairly typical limitation. I'm neutral as to how much they look like links. I'd recommend using icons from our icon theme, or if none or suitable, we should look at using jQuery-UI's icon set for this sort of thing. Note that datatables understand jQuery-UI themes and CSS, which is a nice feature.
You can set the expiration time of the "remember my sorting and filter" option when you construct the table, so having those expire after a day of inactivity, for instance, is easy enough. This is a per-table parameter, so we could make the search results sort preferences long-term persistent while having the pending queue stick around only for a day.
As a final note, my tinkering with Haystack and Solr indicates that the search performance is *dramatically* faster than MySQL (as one would hope), which means that an AJAX-filtered search system will actually perform rather nicely.
- Henry
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.comics.org/r/954/#review2074
-----------------------------------------------------------
Donald Dale Milne
didn't know that" group. If it had an on-page note though, it would be
useable to all of us illiterates. :-)
- Don
Jochen G.
> On 2011-12-24 14:21:55, Jochen G. wrote:
> > Looked a bit more into other django options, but (not surprisingly) these don't handle client side sorting. So this could be used when we can do client-side sorting. For search results this seems problematic because the results can be large, so there we would need server side sorting and pagination. Only for search results with less than, say, 100, results we can use the client-side sorting, so mid-term we need to combine these. Which implies the look and feel should be mostly the same, no matter what solution we use in each case. Or can datatables be used with server-side sorting as well, for cases when the results table would be too large ?
> >
> > One thing we have to think about at one stage is multiple column sorting, here with JavaScript it goes via shift-click. Although I wonder if the average web-user would know to do that (from the few reponses the list: 1 yes / 1 no / 1 didn't mention it) ? Anyway, with a django solution a shift click wouldn't be possible I assume. Does datatables offer alternatives to the shift-click ? Would be moot if we can use (see above) datatables always in the display part.
> >
> > On the list it was mentioned that the headers should display as links, I kind of disagree, since they are not links in the real sense. The 'I am clickable' aspect would come by corresponding arrows, either like django-tables2 https://github.com/bradleyayers/django-tables2 with colored/uncolored arrows, or like on the datables example page where three types of arrows are shown, or something like that.
> >
> > Behaviour wise, I think the current sort behaviour of the pending queue is the most reasonable, changeset with the oldest status change (and which are in pending) on top. That way they are less easy to ignore. Having always one owns sorting makes 'cherry picking' of favourite indexers easier, which is something we shouldn't encourage, I think. There definitly (as also mentioned by Don) should be a way to easily resort to our default sorting. Maybe even fall back to this after a revisit of the page after a certain time, as in keep the sort order during a session, but not over sessions.
> >
> >
>
> Henry Andrews wrote:
> Thanks for the thorough evaluation, Jochen! datatables *can* be used with server-side sorting and pagination as well. It sends AJAX requests to the server to pull up each new page or re-sort the table. It's up to the server code to interpret the request and send a suitable response back with the right data to display. It may even be useful to use the django-tables2 package to generate the data for each request from datatables- I have not looked into that idea at all so far. The one drawback to the AJAX system, as the fellow who worked on django-tables2 mentioned, is that you cannot easily bookmark a particular table state. It's easy to arrange things to allow bookmarking the *initial* state of the table (i.e. of all items, unfiltered), but bookmarking, say, the 2nd page when filtered by publisher and then sorted by first date then title, would require adding a "bookmarkable link" button of some sort that reloaded the page with the right URL. Which also required adding a bit more JavaScript so that the table can be initialized in that paged/sorted/filtered state as well as on the first page. Whether there's a way to have a django-tables2 back end make that easier is not clear to me- I suspect datatables would control the entire front end in a hybrid system. I also suspect that bookmarking all of those different possible states is not a common use case, and an initial implementation that correctly bookmarks the search/filter parameters would be a useful starting point.
>
> In order to use / restore our default sorting we just need to associate it with a column in some way. I'm a little vague on the details, but IIRC you can change the sorting behavior for a column so that instead of directly sorting on the text contents it runs some other function to determine the sort. And of course if you're sorting on the server side you can do whatever you want with it. I'm not certain what interface other than shift-click would be good for multi-column sorts- that's the one I've always seen. Datatables allows up to three, which is also a fairly typical limitation. I'm neutral as to how much they look like links. I'd recommend using icons from our icon theme, or if none or suitable, we should look at using jQuery-UI's icon set for this sort of thing. Note that datatables understand jQuery-UI themes and CSS, which is a nice feature.
>
> You can set the expiration time of the "remember my sorting and filter" option when you construct the table, so having those expire after a day of inactivity, for instance, is easy enough. This is a per-table parameter, so we could make the search results sort preferences long-term persistent while having the pending queue stick around only for a day.
>
> As a final note, my tinkering with Haystack and Solr indicates that the search performance is *dramatically* faster than MySQL (as one would hope), which means that an AJAX-filtered search system will actually perform rather nicely.
>
I don't see bookmarking as a problem, such a link would be in its nature temporary anyway since our data changes all the time, one could even say it is a feature, because a bookmark doesn't make real sense :-)
I am not sure that associating the default sorting with a column is the best way. Then one couldn't do a sorting with that column in a different way I assume. One way would be to have datatables in a 'neutral' mode in the beginning, just display the data as it comes from the server. Or start with the two columns of the default (first state, than date, OK actually we do id as well as the last) as active in regard to sorting. And in both cases a 'default/reset' button of some sort.
The should be icons in the gnome-set we are using in other places.
Expiration should be more in the range of an hour or two. If it is a day and counts from last activity it never would reset for many users who are active daily.
- Jochen
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.comics.org/r/954/#review2074
-----------------------------------------------------------