* This reverts the last commit which documented the old behaviour.
Thinking again about it, if you want to modify the rendered data use
`$(cell).html()`.
* When `dt-init columns.data` / `dt-init columns.render` resolve to a
function, that function is executed. Previously this execution was in
the global scope, but in order to be able to use an instance as a data
source for the row (something I wanted as part of 1.10) we need to
execute the function with the instance's scope. A simple `call()` does
this.
* I could add a check to see if the `rowData` is a plain object or not,
but that would add significant overhead to the processing, and this
particular part of the code needs to be very fast. Additionally, I
think it is unlikely that any one was dependant on this being executed
in global scope, so the change is made.
* This fixes DataTables/DataTables #368.
* 1.10.0 had issues when searching for boolean data as the search
extension methods were checking for empty data, but if found they were
using `''` as the term to filter. It should more accurately just use
the given data.
* Relates, the `_empty()` method was considering `false` to be empty,
but not `true`. Both are now considered to be empty.
* `dt-api state()` - get the last saved state
* `dt-api state.loaded()` - get the state that was loaded when the table
was created
* `dt-api state.save()` - trigger a state save
* `dt-api state.clear()` - clear the saved state
* Fix is to convert from hungarian notation to camelCase in a loop for
the array
New: State staving object structure is now full documentated
* The structure has been altered to be camelCase notation like the rest
of the 1.10 API. State loaded from older versions of DataTables will
be silently ignored
* The native `forEach` is suprisingly slow. I had assumed that it would
be faster that a for loop, but it appears that due to the function
execution it is actually much slower. A simple for loop is much better
for performance and we loose nothing since hte API instance is array
like.
* This fixes DataTables/DataTables #364
* It appears that if you have a reference to a DOM node, but that DOM
node is overwritten by use of innerHTML, the reference is destroyed
and you cannot use the referenced DOM node any more.
* This became apparent from using Editor's inline editing mode, where in
IE the inline edit would work only once. No other browser has this
issue but it is in IE7-DC1.
* The workaround is to remove the child nodes first. not ideal at all,
but it does work.
* Searching the internet I didn't find much about this so I've opened an
issue on the IE connect site:
https://connect.microsoft.com/IE/content/content.aspx?ContentID=29582
* DataTables uses custom jQuery events which propagate up through the
DOM, with the custom event being triggered on the table node. Ideally
I'd like to change the event handling to use $().triggerHandler() to
avoid this issue, but as discussed in issue #245 that would mean that
delegated events wouldn't work. Perhaps there should be two forms of
events triggered by DataTables, those which do bubble and those which
do not. `init` is the only one which would _have_ to bubble.
* The workaround for the moment is to check that the settings object in
context of the executed settings handler is the same as the one that
was used in the addition of the event handler.
* This fixes DataTables/DataTables #361
* In particular this fixes the FixedColumns + ColReorder example which
was showing the problem by expanding the columns to the full container
width for each column. See thread 20848 for information.
