Columns not sorting

ljr1981

Re: Debug output

The numeric columns are sorting with no problem (i.e. Extn and Salary). Other columns will not sort, especially:

1. When a new row is added, the columns will not sort properly.
2. When an existing row (one of the first 57) is edited, the columns will not sort properly.

I know the bug is on my code. The example page sorts in all cases above (and more, I am quite sure).

I have double-checked the javascript to ensure it is up-to-date and that there are no errors (e.g. validate.w3.org) reported. I will keep looking for clues on my own, but perhaps you can spot something.

ljr1981

BTW: Sidebar question—when the AJAX Request is sent, it has a ?_=1498943229089 (and variants of the number) attached to the URI. I know this is a parameter being passed, but have not yet discovered what the parameter is nor its purpose. Anyone know? (I am sure someone does).

kthorngren

i tried the last page you provided in your other post:
http://www.moonshotsoftware.com/datatables_ajax

The test I tried seemed to work. I had the position column sorted and added a new row with the position of "acc" and it was sorted correctly upon insertion.

Maybe you can post exact steps to replicate your problem.

when the AJAX Request is sent, it has a ?_=1498943229089

That is something jQuery does. Its explained here:
http://api.jquery.com/jQuery.ajax/

More specifically:

cache (default: true, false for dataType 'script' and 'jsonp')
Type: Boolean
If set to false, it will force requested pages not to be cached by the browser. Note: Setting cache to false will only work correctly with HEAD and GET requests. It works by appending "_={timestamp}" to the GET parameters. The parameter is not needed for other types of requests, except in IE8 when a POST is made to a URL that has already been requested by a GET.

Kevin

ljr1981

Hey Kevin,

Thanks again! While you did not provide the direct answer, you did indirectly lead me to understand and then correct the problem!

It turns out that the data sent by datatables is formatted as: {key: value, ...}

Notice that there is always a single space between the ":" character and the first character of the "value". THAT was the problem!

My code was doing a split on the ":" (colon) and grabbing the resulting string for the value, starting at the blank space character. This means that the JSON data I was returning as a response to the client browser had this embedded space in front of every value returned.

In a typical string sorter, this was putting those strings to the top of an ascending list. So, regardless of actual value content, the injected space was forcing the sorted item to the top of the list.

I have added code on my side that strips leading and trailing spaces and that has resolved the problem!

ljr1981

One other point to make is this—it appears that the leading space on the numeric value fields was not having the same effect. I think this is perhaps because the JS responsible for those fields is doing a type conversion to numeric and then sorting. Most type conversions from string to number will disregard spaces, make the conversion, and the results will then sort correctly.

If it would NOT be a breaking change for other datatables consumers, I would recommend removing the leading space on the value when sending JSON data to the server. That leading space is of little value to consuming systems. Only human readers would benefit, but human reading is not what this is about, right?

kthorngren

Notice that there is always a single space between the ":" character and the first character of the "value". THAT was the problem!

My code was doing a split on the ":" (colon) and grabbing the resulting string for the value, starting at the blank space character.

I think that is the normal format of a JSON string. An example can be seen here:
https://datatables.net/examples/ajax/objects.html

Click on the AJAX tab to see the format of the JSON string.

Instead of splitting the JSON string maybe you can use JSON.parse.

Kevin

tangerine

My code was doing a split on the ":" (colon) and grabbing the resulting string for the value, starting at the blank space character.

A key:value pair is presented that way so that you can retrieve the key and/or the value by parsing the JSON. Splitting on the colon is not advised.

ljr1981

Hi Kevin,

This is server-side JSON management. You are correct that ultimately I will use a library that consumes the JSON and the space will become moot. However, that stated—the space is similar to syntactical sugar. The spec does not require it or reject it.

ljr1981

Tangerine,

Please refer to the ECMA JSON specifications here. I think I am reading this correctly that a JSON parser disregards the space. In my case, I did not use a server-side parser (a thing I will do in the future). Splitting the key:value pair on the colon is a quick way to get at the value. A LR-parser will trigger on detection of the colon as well, but based on the rules of the parser and not like I have performed it for the moment. That said—splitting on the colon is not inappropriate or wrong. It just works as it does and having the leading space is what caused the issue for me as I chose not to use a JSON parser at this moment. Even using a parser, the leading space would be logically ignored. All I did was recognize that the JSON string coming to the server had this leading space and I needed to equally disregard it and my code then worked.

Thanks for the feedback and input. I appreciate it!

allan

You are correct - white space is irreverent in a JSON data set.

To consume JSON, simply use the built in JSON.parse rather than attempting to do it yourself.

Allan