- DataTables explicitly supports only jQuery 1.7+. `on` and `off` were
introduced in 1.7, so this isn't a problem.
- jQuery migrate shows warnings if bind and unbind are used
- Fixes DataTables/DataTables #853
Previously, date sorting of values that
failed to parse as a date were sorted as
if they were 1970-01-01 (Unix and JS epoch).
Now, they sort before other dates.
Example:
https://jsfiddle.net/qae6zjty/1/
- It is useful to be able to replace some of the utility methods with
your own custom ones - for example a debounce rather than tha throttle
for filtering.
- This commit reorders the code a little to make that possible. No new
code is present at such - its really about reordering the current code
to make `$.fn.dataTable.util` the host for the original functions.
Backwards compatiblity is provided by assigning the util methods to
their old variables. With the next major update they should be removed
and the util methods used directly.
- Other util methods should be added at the same time, escapeHtml,
unique, etc.
- Fixes DataTables/DataTables #810
- Fixes DataTables/DataTables #800
- Its safe to check for `.length` on `orders` at this point since it can
be either a number, an array or undefined. The number and undefined
conditions have already been checked, so it must be an array (of
whatever length).
* `dt-api rows()` and `dt-api row()` can now be used with a cell from
the table body (not limited to only the `tr` elements
* `dt-api columns()` and `dt-api column()` can now be used with a cell
from the table body (not just the column headers as before)
* All three selector types can use an element with the `data-dt-row`
and / or `data-dt-column` (as approrirate) attributes on them or a
parent. This is useful for API integration with FixedColumns and
Responsive. For example you can now pass a cell in a fixed column
into the `dt-api cell()` method to select the original cell.
- Fix is to remove the name attribute. This would have no effect on the
column width and means the radio element isn't in a group.
- See thread 32931
- Fixes DataTables/DataTables #569
- The scrolling body used to have the header content retained but
hidden, while the footer was just emptied. But if the footer content
is long enough to define the width of the column this results in
column misalignment.
- Fix is to treat the footer in the same way as the header is.
Rational for this is that the number renderer expects a number
input, not HTML, but if non-numeric input is given the value is just
returned (now escaped) - for example an empty string.
- This is so that Buttons (and others) can listen for this event and
create the buttons before the user init functions. Otherwise they
would need a setTimeoutout to be able to access the Buttons methods
immediately.
- Factory builder redesigned to pass in window and document to the
factory method, mandating a small update to the AMD and Browser
loaders
- Main change in is the CommonJS loader which can now optionally have a
window object passed in - if it is not passed in `window` will be used
(if this is the case in a CommonJS environment without a root object
being passed in an error will occur).
- DataTables caches a reference to the jQuery instance so the plug-ins
can easily reference jQuery while retaining their current return of
the module they define. This basically means that DataTables core will
include jQuery for the plug-ins.
- This does increase the core library size by ~160 bytes which is rather
frustrating, but I think this is the correct way to go about it
- With thanks to Evan Carroll for input on this:
https://github.com/DataTables/Plugins/issues/199
Fix: Force a column width if `dt-init scrollX` is specified and a column width is given. This can be overruled if the width given is too small for the content
- We already use the width attribute to determine if the table should
resize dynamically to 100% width, so it makes sense to use that when
scroll-x is enabled as well.
- This still isn't perfect as Chrome seems to change between a
box-sizing calculation depending if scrolling is required or not so
there can be a shift in column widths when changing between a
scrolling state and not (column visibility) which is ugly, but is
proving to be difficult to deal with.
to reproduce the error and it is only occuring on Chrome Mac with a
combination of the CSS in the DataTables demos specifically. This is an
edge case that I'd rather not add code for at the moment.
Fix: Chrome has an odd bug whereby the max-height needs a reflow in order to be correctly calculated - otherwise a gap could appear at the bottom of the table
- Haven't been able to reproduce the Chrome issue in a simple test case
- its something to do with the scrollbars being shown while the scroll
column calculations / updates are being done and then no longer
being needed ater that point.
Dev: Code style updated to match DataTables (unwritten!) standard
Dev: Removed some of the protection on the cell index update on row
delete - it is safe to assume that since we have a cell node, we've
assigned an index to it.
- Using just `datatables` would be difficult since I and others already
publish packages with that name. Anyone using those packages already
would run into real issues if I were to change their meaning and
contents!
- Cannot pass in a `dt` instance - will always use the one from the
jQuery instance given
- Don't check for reinitialisation or for jQuery when working in the
browser - will throw an error if in browser and no jQuery, which is
correct, DataTables needs jQuery
New: CommonJS will load jQuery if it wasn't passed in
Fix: Bootstrap, Foundation and jQuery UI integration Javascript files use module.exports correctly
Dev: Change the file include "function" name to not conflict with `require`
- AMD / RequireJS - The Require documentation strongly discorages using
a named module, but I've used this in the past as the plug-ins need a
name to depend upon themselves. This is still `datatables` but if the
developer is using Require and it resolves automatically to a
different name (which it may depending upon their configuration) they
can use a map option to map their name to `datatables`. See
https://github.com/moment/moment/issues/1095
- CommonJS - Based on the disscussion in
https://github.com/DataTables/Plugins/issues/199 it seems that some
developers like to pass a certain version of jQuery in. This
modification allows them to do so while retaining backwards
compatiblity.
- Integration files - The UMD wrapper for these files have been
restructured to be easier to follow. Also, based on the discussion in
the Plugins issue noted above you can now pass in a jQuery instance or
not and likewise a DataTables object or not.
- To avoid direct conflict with `require()` the build scripts have been
updated to use a "function" called `_buildInclude`. Ultimatily this
should really be updated to use grunt or similar.
- I just updated my PHP and HTML Tidy was not installed which resulted
in the examples in the dist repo all being rewritten unfortunately.
This should stop that happening again.
- This comes about from thread 29819 which highlights that inserting the
buidler string as a variable into the static file causes issues.
- This will only take effect once 1.10.10 has been released
- The fix is to loop over the data array to find the cell. Slower, but
for an edge case I think this is an approriate fix.
- This fixes DataTables/DataTables #653
- The fix is to replace with more approriate options. The jquery
`$.merge` function in particular is useful and array concat when we
don't need to maintain a refernce.
- This fixes DataTables/DataTables #651
- This was caused by using `_fnGetRowElements` to get the cells. While
it was good for performance with large number or rows to do so, it
isn't needed for a single row and a single line of jQuery is simpliler
and doesn't trigger the set function
- Fixes DataTables/DataTables #638
- The issue was effectively duplicate code - for 1.9- compatiblity when
I introduced 1.10 I had the set function run specifically if a DOM
node was given. But later in the 1.10 series when it became possible
to have the data written to an object rather than an array, that code
would itself call the setter, thus leading to two calls when there is
a DOM node present for the row.
- The first is simply to remove the code that was running the setter for
the DOM specific case.
- This fixes DataTables/DataTables #638 and thread 25846. Thanks to
@Jamaur and @strang91 for following up on this.
- The issue was caused by the check for the `bScrollOversize` option
which looks for the container being the same width as its inner
content area. Obviously that happens to be true if there is no
scrollbar. Adding a check for the clientWidth not being 100 as well
resolves this.
- I've also combined the scrollbar width detection with the other
browser detect functions. The two functions were performing very
similar operations and so easily combined
- The browser detect DOM creation will only run once, rather than for
every table initialisation, optimising multi-table loading
- Fixes DataTables/DataTables #633 - Thanks to @nddery and @epitaphmike
for the input
- If d or objectRead were truthful then the row's data object would be
replaced with an empty object. This was one shortcut in code too many!
- Relates to thread 29530 with thanks to idleog.
- This appears to be caused by setting the prototype chain as an object
directly. For example:
var test = function () {};
test.prototype = {};
$.isPlainObject( new test() );
will return `true` with jQuery 2.1.4 (and `false` for 1.11.3).
If an item is added to the prototype object then it will return
`false`, although for some reason that wasn't the case with
DataTables' API prototype.
More investigation required, but for full compatiblity with exisiting
jQuery releases, the correct thing to do here is to build on the
exisiting prototype, which we can do with `$.extend`.
- This is an interesting one, and I suspect a bit of an edge case in the
browsers - what is happening is that the window is going from having a
scrollbar to not having a scrollbar when the scrolling viewport is
collapsed. This causes the browser to show the scrollbars in the
viewport for an instant, even although they aren't actually required.
If the height of the viewport is 53px and you up it to 80 so there are
no scrollbars and reduce it back to 53 the scrollbars are gone! The
browser must be stopping a race condition once the scrollbars are
shown.
- The fix is to use `max-height` for the scrolling container if the
scroll collapse is set and `height` otherwise. The browser native
methods makes the code _much_ easier to work with, more performant and
easier to understand.
column width for these tables. However, that was in error - it is in
fact required still as the smart width calculations cause the browser to
crash (APPCRASH). There is no indication as to why this is, not is it as
simple as just disabling one or two pieces of code to stop the crash.
This leads me to suspect that it is the number of operations being
performed - particularly to do with the cloning of the elements. If this
is the case, then its just never going to work. Also IE6/7 are such a
small market now (thank goodness) this is just a feature that won't be
available in those browsers.
If anyone is interested in working on fixing it, or paying me to do so,
I'm happy to hear from you :-)
Fix: The auto width calculation table, when scrolling is enabled, being inserted into the scrolling container could cause the viewport to scroll, even when the main table doesn't actually need scrolling. This causes the column width calculations to be incorrect by the scrollbar's width. The fix is to have the calculation table `position:absolute` in the scrolling container and height:1px so it has no effect on the vewport's scrolling.
- These two fixes address DataTables/DataTables #612. Kudos to @Delgan
for reporting these issues and supplying test cases - thanks!
Fix: Table could overscroll if `dt-init data` is used to populate the table
This is a fairly significant change to how DataTables operates for the
scrolling width calculations and primarily is due to a simplification
with the use of `clientWidth` to get the scrolling container width.
Rather than getting the offsetWidth and then removing the scrollbar
width if required the `clientWidth` will give us the value directly.
With the scrollbar width already accounted for the scrolling draw code
can be updated to not need to account for it itself.
Finally, when using the `data` property to add data to the table we need
to recalculate the column widths after the first draw, just like with
Ajax loaded data, otherwise the data added won't be taken into account
and we can get an error in the scrolling.
when body's position is changed (left: 375px) _fnBrowserDetect incorrecly calculates offsets. thus header is a bit misaligned. commit changes test object's position to fixed. in this case it's position will
be relative to the viewport not to the body.
When the table was being destroyed and the remove parameter was passed
in as `true` to remove the table from the DOM there was potential for
bound events to not be unbound from the table elements. This was caused
by the use of the `detach` jQuery method which will not remove events.
Furthermore, rows would not be added to the table before this method (or
`remove()`) was called. As such we need to reorder the code slightly -
attach the rows back into the DOM and then remove them (or detach if the
table is left in the DOM) - otherwise rows which were hidden by paging
would not have their events unbound.
Many thanks for KnowledgeNet ( http://kn-it.com/ ) for their support in
finding and allowing this bug to be addressed!
Being able to get and keep a reference to each row is quite important.
You can't use the DataTables row index for this as it can potentially
change, but we can use IDs, based on a unique value for each row in the
data - `dt-init rowId`.
I've made the decision to not require escaping of data in the ID. This
means that selectors can be ID selectors with a cobontation of other
things (#div.class for example) as that really doesn't make much sense
in this contact - you only have rows that you can select from. Not
requiring escaping makes both the client and library code much easier.
This is documented.
The implemention is to store a reference to each row's data object based
on its id allowing for a trivial lookup. The object has its own index
in the `aoData` array, so there is no `indexOf` required. The only
downside is that the index must be updated when a row is deleted. This
is done with a trivial for loop.
* Issue was that an `error` event was being triggered before the
settings object had been configured. There is no option to trigger an
error event in this case.
* Fixes DataTables/DataTables #572
On line 605, column.sTitle is set to the TH's innerHTML.
On line 1816, column.sTitle is compared with cell.html().
If you have child elements with event handlers on them inside the TH, these are not the same in IE8 (see https://gist.github.com/simonbrent/933e552739477f4be3ab#file-test-html)
As a result, the check on 1816 fails, the contents of the cell is replaced, and the event handlers are removed.
Comparing instead with cell[0].innerHTML fixes this issue.
The main change here is to modify `_selector_run` to loop over the
extension functions (if there are any). This involves passing extra
information to the function (selector type so the correct extension can
be used, settings object and selector modifier to pass on to the
extension method).
The _selector_opts function has also been updated to give the ability to
use unknown properteries through a $.extend, rather than writing a three
property object.
Fix: Ellipsis elements didn't have padding which could be jarring when shifting between paging that does and doesn't show ellipsis
This fixes DataTables/DataTables #26
Fix: Scrollbar width was being calculated everytime requested on machines with zero width scrollbars
The scrollbar width calculation method has been rewritten to use a
single element with use of `offsetWidth` and `clientWidth` to calculate
the scrollbar width. This works all the way back to IE6.
_fnAjaxDataSrc will in turn call _fnGetObjectDataFn, which
can be specified by the dataSrc method.
This way the dataSrc can set the recordsTotal parameter on
the json data and the changes will be read into the
recordsTotal/recordsFiltered variables.
* 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...
