After Upgrading, No longer have Row Id in Ajax
After Upgrading, No longer have Row Id in Ajax
mattw
Posts: 54Questions: 10Answers: 0
Hi all! I recently upgraded datatables and the editor. Following the upgrade everything is working except edits and deletes (though we handle creates differently). It seems like the response is no longer giving me the id of the row correctly and then I get a "500 (Internal Server Error)". Any thoughts are appreciated. The server code has not changed. Only the dataTables files that we include.
Response prior to Upgrade:
Object {action: "edit", data: Object, id: 15} -> Note the id
Response After Upgrade:
Object {action: "edit", data: Object} -> Note there is no id
heres a piece of the editor code :
editor = new $$.fn.dataTable.Editor( {
ajax: {
// Specify URL for edit/update
// http://editor.datatables.net/examples/advanced/REST.html
edit: {
type: 'PUT',
dataType:"json",
url: '/_systemedit',
data: function ( d ) {
return JSON.stringify( d );
}
},
remove: {
type: 'DELETE',
url: '/_system.delete'
}
},
idSrc: $:hdrs.getIdSrc(),
This question has accepted answers - jump to:
This discussion has been closed.
Answers
Hi,
The upgrade document is probably worth reading over here. Use the
legacyAjaxoption to enable the 1.4 style of parameters.Allan
Thanks Allan. I was using a different upgrade page and totally missed that! Thank you so much everything is working perfectly. Now I will update the server once this is all set. Have a great day
Perhaps I spoke too soon. All of my edits do indeed work perfectly, but delete does not work with the legacy ajax option. Should DELETE technically work with simply setting the legacy option or is it likely that I need to update the server code even with the legacy ajax option ?
I saw these points
-The server-side code if you are not using the PHP or .NET libraries that are available as part of the Editor package.
- Any server-side code that reads the raw submitted data
If you specify the
legacyAjaxoption it should send the remove request in the same format as 1.4 did. If you use your browser's network tools, have a look at what data it is actually submitting. What is it?Allan
Oh I noticed something weird with the form data. I do not get form data with the upgrade I get "Query String Parameters" only being showed in the developer tools and it looks very funny with each letter being on a new line.
Without the upgrade
d = Object {action: "remove", data: Object, id: Array[1]}
form data = {"action":"remove","data":{},"id":[4752]}:
With the new upgrade
d = Object {action: "remove", id Array[1]}
Query String Parameters =
0:{
1:"
2:a
3:c
4:t
5:i
6:o
7:n
8:"
9::
10:"
11:r
12:e
13:m
14:o
15:v
16:e
17:"
18:,
19:"
20:i
21:d
22:"
23::
24:[
25:"
26:1
27:7
28:"
29:]
30:}
The issue here is that a number of HTTP servers don't actually accept form data with the DELETE verb. A query string is the only way of being sure that it will work with all HTTP servers, so Editor 1.5 actively enforces that I'm afraid. I would suggest just using
return d;(rather than JSON encoding it yourself) and then a little modification to the server-side script to use the query string rather than form data.Sorry - I know that's a pain - I don't really see a better way at the moment other than an option to allow form data (which perhaps I should / should have introduced).
Allan
Thank you Allan, no apology necessary! We love dataTables and will get our stuff running where it needs to be with editor 1.5