Feature request: a way to sort empty values to the bottom always about stupid-table-plugin HOT 15 CLOSED

Here's something that just uses the aftertablesort to push things to the bottom. I have it working for the int and float columns, but I'm having some issues with the string.

Hopefully it'll give you a starting point while I evaluate this feature request.

http://jsfiddle.net/JoeQuery/Zt3uU/5/

from stupid-table-plugin.

Ha, I just came here to request the same thing! Actually, my idea was slightly different - a way to detect inside a custom data type which direction the table is being sorted in. So you can basically say, if we're sorting ascending give anything blank a large value; if we're sorting descending, give it a low value.

This makes it more general, too. You would be able to keep anything you like to the bottom of the table easily (e.g. if you have "-" representing unknown/non-existent).

We would be able to pass a third parameter to the custom sorting function, right? It wouldn't break existing code?

from stupid-table-plugin.

I want as few features as possible to be within the plugin itself. However, I do want to make sure that the plugin provides a sufficient enough interface to accomplish what the dev wants. Essentially I'd prefer to keep the plugin super basic but have an extensive list of recipes that demonstrate various things you can do with the plugin.

@svivian I think your suggestion regarding the additional (optional) direction param and the previously requested ability to specify default sort order would make a good combination that shouldn't introduce much more overhead. @zephyr-dev had created pull request #52 but closed it, stating he found an issue, but it looked good to me.

from stupid-table-plugin.

It doesn't look possible to have a third parameter in the sort function that is meaningful in any way. Perhaps we need to let devs have a way to interface with the sort map before it's applied to all the other columns.

from stupid-table-plugin.

@joequery Do you mean because the compare function must be a standard format? (That's what I'm assuming from the MDN docs here). Possible alternatives I can think of:

1. Changing the sort map like you said. I'm assuming you mean running a callback inside the sort_map function where we could for example set all blank fields to have a high value when sorting ascending (and vice-versa). This would mean an extra pass of all the rows, not sure how much that matters.
2. An extra optional attribute, data-sort-value-desc. So if it exists, that value gets pushed to column. (Might be too much overhead in the HTML though?)
3. Separate sort functions, e.g. blanks-asc and blanks-desc. Then an extra optional attribute on the header cell, e.g. <th data-sort="blanks-asc" data-sort-desc="blanks-desc">field</th>. [Edit: if you implement #52 you'd have to make sure the correct function gets called here, you can't just reverse the sorting.]

from stupid-table-plugin.

@svivian Yeah, I can't figure out how to pass an extra value to the sort functions.

> function comp(a,b,c){console.log(c);return a-b;}
undefined
> var a = [5,2,3,9,1];
undefined
> a.sort(comp("LOL"));
undefined
[ 1, 2, 3, 5, 9 ]

I think option 1 will be the easiest to implement and will allow for the most flexibility.

from stupid-table-plugin.

Just found this question from Stack Overflow. You create a function that returns the standard comparator function, but using a closure (so it includes the parent parameters). Example:

> function compCreate(c) { return function(a,b){console.log(c);return a-b;} }
undefined
> a.sort( compCreate("LOL") );
(4) LOL
[1, 2, 3, 5, 9]

Though I'm not sure how we can easily fit that into the plugin, and if it would require all existing custom sort functions to be rewritten. I think that where we use sort_function we can instead call the compCreate above with parameters and return sort_function from it. I'll have a play with it later tonight.

from stupid-table-plugin.

Nice find. We'll still need to evaluate if that would be preferable to being able to edit the sort map. I'm still learning towards the sort map callback. Maybe both features could coexist.

from stupid-table-plugin.

What would be the difference between the two methods, in what they can do? If they are just doing the same thing (custom ordering) then probably not any sense in having both.

from stupid-table-plugin.

You might be able to support both by checking for the number of arguments
the function takes:

http://stackoverflow.com/questions/4138012/checks-how-many-arguments-a-function-takes-in-javascript

Jeff Pickhardt
[email protected]

On Fri, Feb 22, 2013 at 9:52 AM, Scott [email protected] wrote:

What would be the difference between the two methods, in what they can do?
If they are just doing the same thing (custom ordering) then probably not
any sense in having both.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/54#issuecomment-13958171.

from stupid-table-plugin.

What I mean is: you could support the comparator function method, and the
generator function method, at the same time in a seamless way.

On Fri, Feb 22, 2013 at 10:01 AM, Jeff Pickhardt [email protected]:

You might be able to support both by checking for the number of arguments
the function takes:

http://stackoverflow.com/questions/4138012/checks-how-many-arguments-a-function-takes-in-javascript

Jeff Pickhardt
[email protected]

On Fri, Feb 22, 2013 at 9:52 AM, Scott [email protected] wrote:

What would be the difference between the two methods, in what they can
do? If they are just doing the same thing (custom ordering) then probably
not any sense in having both.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/54#issuecomment-13958171.

from stupid-table-plugin.

OK I have taken a look at the extra parameter method, and it doesn't seem possible. The sorting functions are created before the plugin is instantiated. In other words, the sorting direction variable is not known when the function is created and so cannot be passed by way of a closure. It can be done using a global variable but that's messy.

So probably the sort map callback is the way to go. My only reservation is that we'd now have sorting code in two separate places, the original sort function plus the new callback. And there is only one callback function for all the data types - you'd have to pass the data type into the function and do a switch on it, if you wanted different treatment for different columns.

from stupid-table-plugin.

@joequery Just a quick note, I made some commits in my fork, on a new branch here.
None of them solve this issue directly (in fact one solves #53), but this one does a little prep by passing the sort direction into the sort_map function. I removed the is_sorted_array check as it was doing unnecessary work - it sorts the array anyway, just to check if it's already sorted ;) Anyway let me know what you think, I can send a pull request if you like.

from stupid-table-plugin.

I'm about to get really busy, so I might not be able to check anything out for a week or two. Maybe in that time we can come up with potentially better ideas.

from stupid-table-plugin.

Now implemented and merged into master. Check the README for details.

from stupid-table-plugin.