Replies

• allan Posts: 63,400Questions: 1Answers: 10,451 Site admin

  October 2011

  That comment is actually somewhat out of date now... With DataTables 1.8 you can accept also any JSON data set by using the mDataProp option, described here: http://datatables.net/blog/Extended_data_source_options_with_DataTables . The idea with this is that you shouldn't need to do any post processing at all.
  
  I'll update the documentation :-)
  
  Allan
• GregP Posts: 500Questions: 10Answers: 0

  October 2011 edited October 2011

  After data is returned, you could have success call a function that modifies the returned data. Maybe data comes in as a corporate-customized XML file and you have a client-side function that can convert it to JSON (though realistically, most applications should be doing this conversion on the server side); maybe you need to push missing members into the array (sEcho, iTotalRecords, etc). Once that's all done, the last part of the success callback is to call fnCallback and pass it the modified (now properly formatted in JSON that DataTables can understand) data.
  
  Also, what Allan said!
• __Tango Posts: 4Questions: 0Answers: 0

  October 2011

  Thanks!
  
  Unfortunately, i have a service that i'd like to interact with that does not have the data in any form that's usable (e.g. hash of stuff, not an array at all). The mDataProp doesn't help unless you have an array of objects from what i understand.
  
  Also, even if my data was an array of objects that i could use mDataProp on, i still have some data that is encoded in weird ways (requires moderate parsing to produce something useful for humans). I guess in this case, i could use a renderer. Is that the recommended way of doing things?
  
  The reason my data is so weird is that i'm working with an existing system that can spit out json, but it's in its own format, so i need to do a bunch of processing on it.
• GregP Posts: 500Questions: 10Answers: 0

  October 2011

  So, what I said! ;-)
  
  The vast majority of people just send back properly-formatted JSON. Personally, I feel that even if your server code produces non-recognizable output under normal circumstances, I would set up a resource with its own URL that can take that output and render it to JSON on the server side. It CAN be done on the client side, but I personally don't like that architecture. When I ask the server for something, I want it to be returned in the most instantly-usable form.
  
  But that's just me.
• allan Posts: 63,400Questions: 1Answers: 10,451 Site admin

  October 2011

  There are a couple of plug-ins here which might give you some idea of how to transform your data (although in fairness both of these plug-ins are now completely redundant with the mDataProp support in DataTables :-) ): http://datatables.net/plug-ins/server-data-formats
  
  Allan
• __Tango Posts: 4Questions: 0Answers: 0

  October 2011

  GregP: Thanks. I think you're right, this is what i'm looking for. I tried a couple of combinations of that, can you give an example?
  
  Also, I'm not sure i agree with you on the philosophy of having the server produce something that's immediately usable. If you do that, you are effectively creating a strong linkage between the front and back end. In the specific case i'm working on now, I'm trying to stick to an MVC, where the model and controller are handled on the server side, and the browser ajax client is the view. There are multiple views as well, so changing the server (and potentially other clients) just to suit the data format requested by DataTables doesn't make sense in this case. If there is only one client and the client and server get rolled out together, it's likely that you're right and it would be reasonable to have the tight linkage.
  
  Anyway, thanks a bunch. I'll keep on banging on it, but if you have any examples, that'd be great too. :)
• GregP Posts: 500Questions: 10Answers: 0

  October 2011 edited October 2011

  No particular examples; just talking theory at this point in time. Forgive my indulgent yapping, but I find architecture more interesting in some cases than pure logic.
  
  Ironically, although maybe I phrased it awkwardly, I also prefer an MVC or MVC-like approach. Therefore, I recommended the server-side conversion to AVOID, rather than create tight coupling of the front and back end. To me, if you hand off conversion to the front end, it's manipulating data rather than just providing the presentation and interaction layer. However, if you think of that conversion as simply a necessary step for cosmetic presentation, your point makes good sense.
  
  Both approaches require the same amount of code. I suppose I have historically prefered the sanity of keeping my "translators" centrally located and responsive to the requesting agent. But I can also see how it might be more sane to let the client worry about conversion and have the server be agnostic. It really is a good point.
  
  That being the case, I suppose the most important thing when different agents are going to need different formats of data, is to have a sane data interchange format in the first place. ;-) I have no idea how complex yours is. JSON sure is sane, though!
• __Tango Posts: 4Questions: 0Answers: 0

  October 2011

  Thanks GregP! Don't apologize to me. I'm the same way with design. :)
  
  Anyway, i see your point too, so thanks for that.
  
  In any case, i'm still banging on this. I've actually done most of what i'm looking for by writing renderers for each column/cell, but this seems inelegant to me, so i'll probably spend some more time making it work "right" later. Thanks for the tips though!