Replies

• trikk Posts: 3Questions: 0Answers: 0

  July 2013

  I have a similar issue. My column has a bool value. If its false I`d like to add a class to the whole row. Getting the "tr" or "rowindex" would be a lot easier i the mRender.
• allan Posts: 61,972Questions: 1Answers: 10,160 Site admin

  July 2013

  That information is not available in mRender. Showing the row index isn't something I had thought would be useful in mRender since its meaningless to the user (particularly once they start sorting, filtering etc). I think the only way to get the index would be to use the third parameter (`row` I usually call it) and get its index from the full data array ( fnGetData ).
  
  @trikk - use fnCreatedRow . Much easier :-)
  
  Allan
• trikk Posts: 3Questions: 0Answers: 0

  July 2013

  Thanks.
  
  I had the same idea :-)
• roncemer Posts: 4Questions: 0Answers: 0

  May 2014

  This is a major oversight on the part of the DataTables development team. In deprecating and removing fnRender() and not providing a suitable substitute, you've painted your users into a corner, providing us with no valid upgrade path to DataTables 1.10.

  I developed and maintain the JAX Framework http://sourceforge.net/projects/jaxframework/ which makes extensive use of DataTables, including using fnRender() to accomplish things the DataTables designers probably never thought of. This includes using iDataRow to number the rows, using helper functions to find other columns in aoColumnDefs, and dynamically rendering cells as HTML input elements to allow users to edit the data in-place.

  Not providing access to the oObj argument that was available in fnRender() is a major problem. That oObj argument provides me with everything I need to be able to access the DataTable instance in use, find its aoColumns / aoColumnDefs, do introspection on the DataTable itself, get the actual row index (iDataRow) and column index (iDataColumn) into the array of row/column data for direct introspection and manipulation, and even provide line numbers on things such as Sales Orders and Purchase Orders which I use DataTables to edit.

  I propose that, at a minimum, you add a fourth argument similar to oObj to the mData() and mRender() functions, so that all of this functionality which you've disabled can be re-enabled. It is not wise to take away functionality which already existed. You never know who was using it. In this case, it had a big impact on a very important project. Several multi-million-dollar companies' backends are running on JAX Framework-based applications. They count on me to be able to keep JAX Framework updated with the latest third-party modules (jquery, jquery-ui, various jquery modules including DataTables). To eliminate fnRender() without replacing it with a viable alternative, is irresponsible. It's bad enough that I have to go back through all of my clients' code base and replace fnRender() with mRender(). But to make it impossible to upgrade, period...well, that's beyond the pale of cavalier irresponsibility.

  Consider the jquery migration module. At a minimum, you should provide something similar for DataTables. Just another JS include which extends DataTables to provide the missing fnRender() function, along with anything else which was carelessly ripped out without providing an equivalent replacement. This should be a permanent solution so users who don't want to migrate from the fnRender() model can be assured that their code (in my case, many thousands of lines of code) won't be "rendered" useless in the next release of DataTables.

  Unless this is fixed, right away, then my only alternative is to migrate to another solution. And that will be costly as well -- VERY costly, since the entire framework is DataTables-centric.
• allan Posts: 61,972Questions: 1Answers: 10,160 Site admin

  May 2014

  Hi,

  Thanks for the feedback. Firstly I would say that you don't have to upgrade. If you need to keep using fnRender, then keep using 1.9.4 :-). I can provide support for the 1.9.x range if required (free support is available for only the current release, but the professional support packages can be made to suit your needs).

  Secondly, I made it very clear throughout the whole 1.9.x series that fnRender would be removed from DataTables in the 1.10 release. It was slow, cumbersome and seriously hampered development of DataTables. A lot of the features and performance enhancements that are now possible in 1.10 are directly due to the fact that fnRender was removed. I didn't want to hold back development of DataTables rationing support for fnRender.

  The reason that there is no direct compatibility for it is that it was tied directly into how DataTables handled the data. columns.data, columns.render, columns.createdCell and createdRow should be able to do anything fnRender could do, and more.

  I appreciate that have a feature removed is not fun, but it (in my opinion as the author of DataTables) had to be done for the future development of the library.

  Including the row index and column index in the data fetch functions does sound like a good idea, and something I will look at adding.

  Allan
• allan Posts: 61,972Questions: 1Answers: 10,160 Site admin

  May 2014

  Been thinking how I might implement this while I was on my way home. I might have a nice little way of doing it, but will experiment a bit and post back with how I get on.

  Allan