* This is actually compatible with 1.10.0+ but was never documented (it
wasn't an intended feature, but rather an implementation detail. It
is rather useful though, so is now documented.
* `alert` - Alert the error
* `throw` - Throw an error
* `none` - Do nothing
* A function that is called
New: `dt-event error` event that is triggered when an error occurs (regardless of the value of `$.fn.dataTable.ext.errMode`
Previously the whole row was invalidated as a quick workaround for what
I would would be a complex task, but the solution is actually relatively
simple and small in code size, reusing much of the current invalidation
code. The cache data for the whole row is still removed, but the
important part of minimising the DOM interaction is in place.
Fix: Incorrect returns from sub-methods if a selector does not contain any results (DataTables/DataTables #431)
Update: `dt-api iterator()` has a fourth parameter to indicate that a return value is expected
The basic issue here was the `iterator()`'s automatic check to see if a
new API instance should be returned or not. If there are no results from
a selector the iterator will just use the original API instance to
return, but this isn't correct as we expect an empty result set in this
case. This is partly due to the fact that the top level methods (`row()`
for example) will return 2D arrays, while the child methods will flatten
the results, this is parhaps an error in the API, but too late to fix
now.
To address this, `iterator()` now has a parameter to tell it if a new
instance should be used or not. I debated about a new method
`iteratorNew()`, but I think this is just as clear (which isn't very
clear unfortunatly, but just needs to be made clear in the
documentation, which I've updated for this change).
I've added tests for the selectors with `deferRender` enabled. The test
suite is still in desperate need of update...
This is something that has been in DataTables since the version first
vresion and was contentious at that point so while this is a minor code
change, for me it is quite a big change! I feel that this is the correct
operation now, although it does result in rows being moved around where
they might not be needed to if partial pages could be used.
Improved last page calculation when page size is changed on last page.
e.g. Suppose there are total 12 records and page size is set to 5 records/page. Go to last page, which should be 3, change page size to 10. Page#2 should be selected and it should show 2 records on it.
* 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.
* V8 strips unknown characters not only at the start of a string given
to Date.parse() but also at the end. So `10%` (for example) was being
detected as a date type.
* This fixes DataTables/DataTables #354
* This is likely to be of more interest to plug-in authors rather than
for general DataTables usage, but I've found myself wanting it a
couple of times recently for plug-ins.
New: `dt-api row().child.remove()` and `dt-api row().child().remove()` methods to provide the ability to remove and destroy child rows
Fix docs: Note that the row().child() method's return value can have an effect on the chaining
* This fixed DataTables/DataTables issue #326.
* Special thanks to `Scottmitch1` (on github) for help with this one!
Dev: Modify the initialisation of _Api - the old method of using `=`
twice on a row caused Chrome's debugger to show it as both names
concatinated which was confusing.
Fix: Remove API "build" code. That was part of the API prototype and the
design moved away from that approach. The code was redundant and unused.
* Originally this was done because it makes removing items a little bit
easier with Array.splice(), however, it doesn't make any sense to go
through the rows in reverse if there might be an interdependency
between the rows.
* It has never been documented what order the rows are filtered in, so I
think this is a safe change to make.
* I've also added the row display index to the parameters passed in
* This fix was partly committed earlier by mistake [b7feaa2]
* The fix is simply to store the draw hold state and make use of it in
the draw scroll callback.
* In IE8 if the DataTables width calculation functions were being
triggered DataTables would clone the table node and then do a jQuery
$().remove() on the cloned node. This was bad in IE8 as it meant that
on the remove the events that were attached tot he original table were
removed as well as the ones on the clone table. IE8 must retain some
kind of link between the original and clone nodes. Using jQuery's
clone() method resolves this.
* See thread 21040 for more information
* Previously the filter builder was created as a string, so we had to
escape quotes, otherwise it could create invalid HTML. That is no
longer the case as we are using jQuery DOM manipulation, so the escape
is redundant and potentially harmful
* See thread 21197
* Due to the manipulation of DOM elements rather than strings for the
length list, the browser was cropping elements which were being cut
short. Fix is to switch back to string manipulation, which can be done
easily using the outerHTML property of the DOM element. This is
supported in all browsers since Firefox 11, so happy to use it here.
* See thread 21170 for more information
* The two data handling functions for each column are now given a forth
parameter if you are using them as a function. This new parameter
gives index position information about the cell in question, as well
as access to the settings object.
* This additional information allows abstraction functions to be created
external to DataTables that can be reused for different columns, with
those abstraction functions now having access to the information about
the cell they are operating on. For example, you might have a number
formatting function which can be reused, and it will determine what
data to read based on the column index given.
* This additional information is required in order to be able to fully
replace fnRender which was removed in DataTables 1.10.
* This fixes DataTables/DataTables #321
* Documentation updated, including an error fix for columns.data
* The error was that the registered cells array was growing on every
call, so the processing took longer and the memory usage went up
* See thread 21063 for details
