Extended data source options with DataTables
Extended data source options with DataTables
Hello all,
Alongside the release of DataTables 1.8 beta 1, I've introduced a new section to the DataTables web-site - a blog :-). In the blog I'll give examples of how DataTables can be used in sites, and discuss various techniques for interacting with DataTables.
The first post is called "Extended data source options with DataTables": http://datatables.net/blog/Extended_data_source_options_with_DataTables
Rather than have comments at the bottom of the post, I plan to have post-blog discussion here in the forum. I'll create a new thread for each forum post for the discussion.
Any and all feedback on the first post and how I've pitched it is most welcome!
Enjoy,
Allan
Alongside the release of DataTables 1.8 beta 1, I've introduced a new section to the DataTables web-site - a blog :-). In the blog I'll give examples of how DataTables can be used in sites, and discuss various techniques for interacting with DataTables.
The first post is called "Extended data source options with DataTables": http://datatables.net/blog/Extended_data_source_options_with_DataTables
Rather than have comments at the bottom of the post, I plan to have post-blog discussion here in the forum. I'll create a new thread for each forum post for the discussion.
Any and all feedback on the first post and how I've pitched it is most welcome!
Enjoy,
Allan
This discussion has been closed.
Replies
Two, apologies for the duplicate here http://datatables.net/forums/comments.php?DiscussionID=4878&page=1#Item_2 so i'll just move the discussion here so that other people can benefit.
Took your advice and checked out the new version 1.8-beta1 ... quite cool. Upgraded and everything worked out quite fine!
However, I added this to my js call to try take advantage of the new data handling feature... the table stopped working ...
[code]
"aoColumns": [
{ "mDataProp": "fullname" },
{ "mDataProp": "extended.0" },
{ "mDataProp": "user_group" },
{ "mDataProp": "gender" },
]
[/code]
My server side column specification in the php file is
[code]
$aColumns = array( 'fullname','extended','user_group','gender');
[/code]
Please note that the extended field holds a JSON array & without the "aoColumns" specification the table works however the extended field holds the entire JSON array hence why I was trying to fetch the first field using "extended.0"
Any ideas what I could be doing wrong. Have gone through the docs countless times :-( and even checked my syntax ...
An example of the data held in the extended field is
[code]
{
"check_in_date":"5",
"check_in_month":"04",
"check_in_year":"2011",
"institution":"Choice 2",
"degree":"Choice 2",
"field_of_study":
"Electornics and Computer Engineering",
"major":"Engineering",
"year_of_study":"Choice 2",
"gpa":"Choice 2",
"motivational":"Motivated",
"industry":"Choice 2",
"duration":"2","employment":"1",
"renumeration":"0",
}
[/code]
The only thing that I can come up with is that the resultant array returned by the server side script doesn't obey the array structure that datatables expects since it puts the array above in another array "aaData"
Just my two cents
My situation is more of an object of an object and so your deeply nested example is closest to my situation ... this is your example data from deep.txt (please note that the object in 'platform isn't in quotes')
[code]
{ "aaData": [
{
"engine": "Trident",
"browser": "Internet Explorer 4.0",
"platform": {
"inner": "Win 95+",
"details": [
"4",
"X"
]
}
}
] }
[/code]
In my case, I had a JSON string stored in the extended field ... wouldn't the result of the extended field be placed inside double quotes? " .. " Something like this ... (See the difference in the platform field which is now in quotes)
[code]
{ "aaData": [
{
"engine": "Trident",
"browser": "Internet Explorer 4.0",
"platform": "{
"inner": "Win 95+",
"details": [
"4",
"X"
]
}"
}
] }
[/code]
Could this be the reason, however small affect datatables and cause it not to understand the result of the server-side script?
Hope this helps!
Allan
[code]
"aoColumns": [
{ "mDataProp": "fullname" },
{ "mDataProp": "extended" },
{ "mDataProp": "user_group" },
{ "mDataProp": "gender" }
]
[/code]
and my server side column arrangement call is
[code]$aColumns = array('fullname','extended','user_group','gender');[/code]
This is the result of from the server side ... (just place the output of the server side on the page for debugging purposes)
[code]
{
"sEcho": 0,
"iTotalRecords": "5",
"iTotalDisplayRecords": "5",
"aaData": [
{
"fullname": "Job King'ori Maina",
"extended": "{\"check_in_date\":\"5\",\"check_in_month\":\"04\",\"check_in_year\":\"2011\",\"institution\":\"Choice 2\",\"degree\":\"Choice 2\",\"field_of_study\":\"Electornics and Computer Engineering\",\"major\":\"Engineering\",\"year_of_study\":\"Choice 2\",\"gpa\":\"Choice 2\",\"motivational\":\"Motivated\",\"industry\":\"Choice 2\",\"duration\":\"2\",\"employment\":\"1\",\"renumeration\":\"0\",\"login-updprof-btn\":\"Update Profile\"}",
"user_group": "3",
"gender": "1"
}
]
}
[/code]
The JSON above is valid JSON but where did all the '\' come from? Could the server-side script be adding these modifications and could this affect when I try access nested fields e.g. { "mDataProp": "extended.institution" } When I check the database directly this is what I get in the extended field ... so my date is on
[code]
{
"check_in_date": "5",
"check_in_month": "04",
"check_in_year": "2011",
"institution": "Choice 2",
"degree": "Choice 2",
"field_of_study": "Electornics and Computer Engineering",
"major": "Engineering",
"year_of_study": "Choice 2",
"gpa": "Choice 2",
"motivational": "Motivated",
"industry": "Choice 2",
"duration": "2",
"employment": "1",
"renumeration": "0",
"login-updprof-btn": "Update Profile"
}
[/code]
Allan
In the docs, the server side php script is already designed to return an appropriate JSON result with correct encoding right? Ok, that may be just an assumption, just thought if its in the examples then it abides by the rules. So ... does this mean that due to my unique extended field data I need to make modifications to adjust to my situation and treat that field as having JSON?
I must say thank you Allan. Really thanks. Its been a steep learning curve throughout the week but I believe I'm at the last step! :-)
Allan
Makes sense why the entire json string is placed in quotes ... also thought it was weird that jsonlint wouldn't auto indent the json extended field data when I was validating it ...
Anyway, I was perusing all the server processing PHP scripts in your examples and I realised something. its very easy to assume that the scripts are identical but in fact they aren't in that, the way they process the output array is a little different. This might have been obvious to you since its your code :-) but its made me realise why I've been getting unexpected results.
Now with a little more direction :-) Lemme read up a little bit and see how I can format that output array ...
Funny how what you've been trying to explain all this time now just comes together! :-)
Btw - you should be able to just do something like $myArray[] = json_decode( $myJsonString );
Allan
I think you have a done a great job even with the server-side scripts. The examples really nail it even further its just that, in my case I thought the script handled all situations and my situation was a bit different. Maybe you could add this scenario to the server-side processing examples so that other people can benefit. Plus the ajax examples and the different scenarios i.e object with subarray, array with subobject, deeply nested should serve as a good indicator to show that the output format of the source is really important.
It might be difficult to come up with a script that covers all possible scenarios so also a blog post about modifying the server-side script to cater for individual formatting needs might come in handy :-)
So for anyone else out there who might have had the same situation as I did, here are my modifications to the server side script.
[code]
while ( $aRow = mysql_fetch_array( $rResult ) )
{
$row = array();
for ( $i=0 ; $i
Hmmm...now that I take a quick look around the docs again, I'm not sure the new feature goes that far. I would like to be able to use the mDataProp defined for a column as the parameter to, for instance, fnFilter. If that's not currently possible, I would add that as a feature request :)[update: I see now that it doesn't do this]
Over time, you've gradually added a bunch of the mods I had (sorry, never really had the time to test properly and share back) which is awesome because I won't have to merge in updates anymore...well, after just one more thing gets added: metadata plugin support(but I'll bring this up in another post)
Anyway, the blog post does a great job of presenting the feature and what one might do with it.
I am coming from a .NET background and this just makes my life much, much easier. Now I can just list out my classes from the javascript webservice, and the column properties will take care of the rest. So awesome.
Thanks!
@pimperish: Column references are still done on an index basis through the API, rather than by name. However I would imagine that it would be quite trivial to have a plug-in API function to take a name and match it up to an index given by sName - then fnFilter could be done by something like fnFilter( 'allan', 'col1' ); - is that the kind of thing you mean? It's a nice idea that certainly.
Regards,
Allan
"aoColumns": [
{"sTitle": "Status", "mDataProp": "requestStatus.status" },
{"sTitle": "Mission", "mDataProp": "overview.feedOverview.status" } ]
JSON
{
"aaData": [
{
"requestStatus": {
"status": "OPERATION_COMPLETE",
"errorText": null
},
"overview": {
"feedOverview": [
{
"status": "RUNNING",
"recordingStatus": "STOPPED",
"picteId": "1323369508",
"feedName": "Predator",
"missionName": "Mission",
"startTime": "2011-12-08T12:00:00",
"stopTime": "2011-12-08T16:00:00"
}
]
}
}
]
}
[code]
$('#example').dataTable( {
"bFilter": false,
"bPaginate": false,
"bInfo": false,
"bJQueryUI": true,
"bSort": false,
"bProcessing": false,
"sAjaxSource": "url",
"aoColumns": [
{"sTitle": "Status", "mDataProp": "requestStatus.status" },
{"sTitle": "Mission", "mDataProp": "overview.feedOverview.status" } ] });
[/code]
[code]
overview.feedOverview.0.status
[/code]
for your mDataProp there.
Allan
However I'm trying to figure out how to use this gracefully with fnRender. I've adopted this generic approach:
[code]
"aoColumns": [
{
"mDataProp": "someKey",
"fnRender": function (o) {
var v = o.aData[this.mDataProp];
// return 'v' with formatting
}
}
]
[/code]
Maybe the value of the current column could be made available automatically? For example:
[code]
"fnRender": function (o, v) {
// return 'v' with formatting
}
[/code]
Developers could still access any other column the old way.
It will probably be the start of next week before I can do that, but I'll get it into DataTables 1.9.
Regards,
Allan
Regards,
Allan
It seems to me that column sorting is the next thing that needs to be less dependent on array indexes. In our current app it's causing us some trouble. When we sort on column 3, for example, the datatable service is called with iSortCol_0 set to 3. If we add a new column to the left later on, that same column is now column 4.
This requires us to maintain an array of field names in our service, and if the above happens we need to update the array to match the integer the datatable is sending. If we have two different datatables using the same service but displaying different data, we have to maintain an array for each. It's a lot of logic that seems unnecessary -- the service shouldn't have to worry about any of this. Things get even weirder when we need to create fake columns that aren't in the original data.
The solution to everything is to set iSortCol_0 to a field name (mDataProp) instead of an integer. No more updates to the service and no more maintaining arrays.
Does the datatables framework already support this kind of sorting? If not, would you be open to implementing it?
Yes DataTables provides the information to solve this particular problem already :-). The key thing to remember here is that I've tried to strike a balance between ease of use for initial setup (the most common usage is index based) and flexibility (mDataProp). I don't want developers to need to specify mDataProp for every single table - obviously there are cases where it will be needed for all tables on a site, but it isn't needed for reading from a DOM source for example.
DataTables sets the mDataProp_{int} for each column. So if you get the first sorting column as column index 3, you would look up what the mDataProp for that is using mDataProp_3. If you have a look at this script, you'll see that I've got this conversion in there: https://github.com/DataTables/DataTables/blob/master/examples/server_side/scripts/objects.php .
Allan
Can you please help me to see how do I get nested array data, if number of items in the sub array is dynamic, see below for my data set (in details )? So I can't just hard code details.0.name, because number of items in details array is dynamic.And I am doing server side fetch.
{ "aaData": [
{
"engine": "Trident",
"browser": "Internet Explorer 4.0",
"platform": {
"inner": "Win 95+",
"details": [
{"name":'a',"class"='1'},{"name":'b',"class"='2'},{"name":'c',"class"='3'}
]
}
}
] }
Regards,
Allan