…etting a TH cell's position in the table as well as TR and TD elements. The input and output options for the function have not changed - just it's internal operation.
…ividual value, an array or an object as the first parameter passed to it. The individual and array options behave exactly as they did before this change - the new option is the object being passed in. This allows fnupdate to be given a data object which is identical to data objects used by the table when using complex objects and mDataProp. How fnUpdate itself actually operates has also changed to be self calling, which makes the multipe column updates for arrays and objects much easier. Fix: fnUpdate now works with TH elements in the body as well as TD elements
…ery start of each table draw (so rather like fnDrawCallback, just before the draw!). This function is, like all other DataTables callbacks, execuated with the DataTables instance scope, and also takes a single parameter - the DataTables settings object. The attached function can cancel the draw by returning false, anyother return (including undefined) results in the full draw occuring).
…'s data is Ajax sourced, and at the first draw only. This provides an indication that the data is currently being sourced from the server (i.e. Loading...) rather than showing 'No data available in table' - which is not particularly friendly. Note that for server-side processing, DataTables will leave whatever is in TBODY when it makes the first Ajax request, so with server-side processing you would need to put in a TR/TD into the static HTML table.
…next column was hidden as well. Need to 'fast-forward' to the next visible column to get the insert point.
…he use of a 'td' selector. The fix for this is to use _fnGetTdNodes() (since that can get an array of TD|TH nodes, which in turn allows a nice tidy up of the insert part of the function.
…to the offset calculation done with the huge flat array of TD nodes. The fix is to simplify this somewhat and get an array for each row (when it is available) and process that using the optional parameter for _fnGetTdNodes. This doesn't result any any extra computation time, other than the addional time to call the function (but not to execute it), since it is just moving where the loop is.
…n x-scrolling is enabled. Basically browsers need a bit of a hand when a width is assigned to any columns when x-scrolling as they tend to collapse the table to the min-width, even if we sent the column widths. So we need to keep track of what the table width should be by summing the user given values, and the automatic values
…lations to go completely off since they weren't actually used by the browser. Make use of the _fnStringToCss helper function for exactly this kind of thing.
…g on an extra string to the content of the columns in the width calculation table, in order to take account of the fact that 'iii' is actually less wide than 'mm', but DataTables will pick 'iii' as the longer due to the string width. With sContentPadding you can add an extra string to any column to force DataTables to take account of this during the width calculation - the string in sContentPadding is not used anywhere else and is empty by default. This option will remain undocumented for the moment, since I suspect it will confuse more than help, but it is very useful to have around when x-scrolling.
… we are going to be using strings for the display - so cast as a string, which means that we can take the length of any primitive (particularly numbers). Fix: The max string width calculation was including HTML, which is just plain wrong since the HTML will be hidden. This is still not perfect since "iiii" takes less space than "mmm" in the browser display, but addressing that would take some serious clocks cycles, and this is good enough for now.
…lumns, so _fnGetWidestNode need only deal with column indexes. It was possible before that the width calculation would be done in the wrong column if using hidden columns
…array that DataTables uses for rendering the actual table. This was part of the original commit for the 1.8 object handling, but in retrospect, the original data is much more useful.
…splay, otherwise a null element (particularly when using a null mDataProp) can cause issues with columns being skipped (due to the null return)
…g function was called, it wasn't actually saved anywhere. This meant that when the cell was actually created and the data source attempted to be read, the rendered string wasn't available - thus you got an empty cell (4943). This fix is to add a condition to the rendering call to delay until the node is created. Note that there is still a quirk here, in that the rendered data cannot be used for sorting or filtering, since again it isn't stored anywhere when the data source is null.
…roperty allows a default value to be given for a column's data, and will be used whenever a null data source is encountered (this can be because mDataProp is set to null, or because the data source itself is null). In addition to this, when set if the mDataProp value is undefined, the default will be used instead (and no error given). If sDefaultContent is not set (default is null), and the mDataProp value is undefined, an error will be given as it currently is.
…mmit is the correct one. Updating fnUpdate to be able to cope with bDeferRender
… text rather than HTML when doing the width calculations - making them completely wrong - 4879
…on in full_buttons pagination, when not using jQuery UI themeing to make styling easier
…nts as well as TD in the body. Also correctly consider complex headers
…cause indexing problems for the width calculation due to a getElementsByTagName('td'). Now use the _fnGetTdNodes (slightly modified) to do this.
…orting classes weren't being appled - 4927
…uding null and boolean etc). Add suitable unit tests to sanity check this.
…eated just like TDs in the body. This will work only with DOM sourced data out of the box - any body cell elements that DataTables creates are still TD.