newly created elements
- The fix i've put in is basically the same as what DataTables 1.9-
used. I had tried to opitmise it a little, but it wasn't working for
newly created cells. I still think this can be optimised, but for the
moment, this is at least allows it to work.
and result set for the plural methods.
Fix: Row details events were itterating over non-DataTables rows
creating a Javascript error
Fix: Example - Server-side processing row details example updated to be
able to restore the details row on a redraw.
Update: Documentation - Most examples which used `flatten()` are more
correct to use the new `eq()` method, so they have been updated.
- This set of changes is based on the discussion in thread 19377. While
working on the fix, I realised that the use of flatten() is too broad,
so the new `eq()` function is introduced. It is similar to the jQuery
eq() method in that it reduces the instance to just the selected
index, although in DataTables this is both the context and the result
set. Its a small addition, but I think it will provide to be very
useful
DataTables which character is used as a decimal place in the table's
data, so that number which are formatted using characters other than a
dot as the decimal place can be correctly detected and sorted.
- A large part of the world uses the comma as a decimal place, so it
makes sense to have this option built-in directly to DataTables,
rather than needing to use plu-in sorting types as before:
http://en.wikipedia.org/wiki/Decimal_mark
- However, the decimal place character cannot be detected automatically
since there are far to many ambiguities. As such, a new
`language.decimal` option is defined which is passed through to the
type detection functions. The type detection functions can then use
that character to alter their detection functions to transform numbers
into the dot formatted equivilent for parsing in Javascript.
- The numeric sorting methods have been bundled together in the function
`_addNumericSort` which is called when a character is given for the
decimal mark, adding the sorting functions required specifically for
that mark. This means that any character at all can be added, while
keeping the table's sort performance as it was.
- Code size in increased a little for this new feature, but a lot of
work has been done to keep it to a minimum (while still optimising for
the most common use case of a dot decimal place), and this is a good
feature to have in DataTables' core code.
- All required documentation added and updated.
- Special thanks to Tobias Bäthge for suggesting and sponsoring this
feature.
- This is caused due to different content in the displayed header and
the size forcing header in the body scrolling table. The browsers can
lay the two tables out differently even although the widths applied
are identical, due to the different content.
- The fix is to keep the content in the scroll body header, but hide it
by wrapping in a div which has height 0 and overflow hidden
- See thread 19311 for more information
server-side processing
- A popular plug-in for DataTables is the `fnSetFilteringDelay` plug-in,
which provides a bit of a buffer when typing into the filter input so
you don't make an Ajax request for every key stroke - i.e. don't DDoS
your own server!
- Since we have _fnThrottle built in now for the scrolling, we can also
use it to provide this buffering functionality for server-side
processing filtering in the core. A couple of small changes for
_fnThrottle were required to get the callback context correct and ot
call it not immediately, but only after the delay
footer
Update: Update CSS to display the table border properly when there is no
footer when scrolling
Dev: Update the _fnAddOptionsHtml function to be smaller in code size.
Identical functionality, just smaller code
fact that the table width attribute has been removed, but was being
applied to the table anyway, as 0px - causing the table to be as narrow
as possible. On the plus size, the columns kept their alignment with
such a misconfiguration! However, now the `width` option for columns is
correctly applied in x-scrolling tables.
don't need to look it up with inArray. Also the header renderer does not
pass in the column index now (the column.idx property can be used). This
is to allow operations such as ColReorder to reorder teh columns and
still have the renderers update correctly
- Column width is always a particularly difficult one to get quite
right. In this case, the fix is to have DataTables read column width
information from the `width` or `style` attributes of a column header
cell, if that information is present. If it is, it is treated as
sWidth is (although user supplied sWidth can override). That is it say
that it will be applied to the column width calculation table.
- The remaining gap is if a developer assigns a width using css classes.
We can't get that information, so we fall into the old problem.
- This change comes about from the discussion in
http://datatables.net/forums/discussion/19089 and the fiddle here:
http://jsfiddle.net/EysLd/1/
- What is happening in the test case is that the calculation table is
being created, but it is then stripped of widths due to this commit:
https://github.com/DataTables/DataTables/commit/6a9e324 . That was to
allow DataTables column headers to have their applied size removed, so
a new size could be calculated. Only sWidth would override that - now
the width and style attributes will as well
- IE8- requires that Function.prototype.apply be used with an array or
arguments object as the second parameter - it being "array-like" isn't
good enough.
- This fixes DataTables/DataTables #262
plug-ins
- A lot of plug-ins use _fnCalculateEnd and although all that is needed
in the upgrade is to remove it, since the value is calculated
automatically now, it will likely cause confusion and hassle. So I've
added this stub to prevent those errors.
- Chrome (V8) will incorrectly detect '$245.12' and similar as dates,
since V8 will strip unknown characters from a string given to
Date.parse and then attempt to parse the rest of the string - in the
example above: Dec, 245:
https://code.google.com/p/v8/source/browse/trunk/src/dateparser-inl.h#72
- The fix implemented to to check for a leading a-zA-Z, number or +-.
Although this isn't a perfect match for what Chrome does, it, I think,
a good enough effort to chatch nearly all particular use cases.
- Additionaly, V8 will try to parse a single number passed into
Date.parse - 1-12 are months, 32+ are years. As such, the numeric type
detection much be a highter priority than the date detection, since
Chrome might incorrectly use a column as a date. It would sort
correctly, but it isn't "correct".
- The take away from this is that Date.parse cannot be used for date
format validation on its own...
1D arrays.
- The method implemented isn't actually 100% perfect - if you mix arrays
and scalars, then the behaviour is undefined. But that shouldn't
happen in DataTables. Will look into it further, though
- This is actually a little more complex than it might first appear
since any classes which have been added by DT_RowClass need to be
removed. We can't just bindly remove all classes, so we need to track
that classes have been added in a private variable.
- It appears that ti is impossible to know in CSS if a table doesn't
have a tfoot element reliably and cross browser, so I've added a class
which is added to the table automatically if the table has no footer
or the fotoer is empty to complete the styling of the table.
- Fixed error when there are no cells in an empty TR row in the footer.
- With the change to camelCase, it is easier to extend the usageof
optiosn now, and in this case I've allowed the `orderFixed` (formally
`aaSortingFixed` parameter to be passed in as an object as well as an
array. As an object the `pre` and `post` parameters are used to
specify prefix and / or postfix ordering. Useful for gouping.
- The _pluck() function that was being used to get the tr elements
didn't remove nulls, while jQuery doesn't like removing a class from!
- Thanks to `RagingTroll` in the forums for spotting this:
http://datatables.net/forums/discussion/18651
the property being expanded is an object or not. If not, then set it to
be an empty object which will be extended. Only really effected the
`ajax` property
Based on the discussion in the forms (
http://datatables.net/forums/discussion/18456 ) the fix from 8935b8a
wasn't good enough. What was happening was that the _save_data function
was doing a deep copy of all arrays (minus the data array) so the
default sort was stil applied.
The fix is to reinstate the _fnExtend function which does a jQuery like
deep extend on objects and a shallow extend on arrays. That is extended
slightly to allow array references to be broken on initialisation, to
resolve the issue 8935b8a attempted to (sorting array would be used for
two tables for example), by an optional parameter. This should resolve
the issue correctly this time!
- This fixes DataTables/DataTables issue #241.
- Most of the properties attached are objects, so we want the references
to them, rather than a copy, so a simple assignment is all that is
needed. Strings etc will continue to work as well.
syntax paraneter names
- Data added using fnServerParams with array syntax had different
behaviour in 1.10 from 1.9. In 1.9 jQuery would create an array for
us, but in 1.10 before we create an object first, we need to create
that array ourselves. So the following code had different behaviour:
"sAjaxSource": "data/arrays.txt",
"fnServerParams": function ( d ) {
d.push(
{name: 'somekey[]', value: 'somevalue1'},
{name: 'somekey[]', value: 'somevalue2'}
);
}
In 1.10 it would have sent `somekey[] = somevalue2` but 1.9 would have
sent both as part of an array.
To maintain full compatiblity with 1.9 we need to convert this syntax to
an array - this commit does that.
I was concerned about using parameters in the brackets, but jQuery only
searches for `[]` when performing this conversion. We could use $.param
and then decode the created query string, which would be absolutely 100%
comaptible, but would involve additional code and I think this method
provides that 100% compatiblity from reading the jQuery code), and its
shorter.
- The ability to use negative numbers as a column selector for the
column data index was added recently, but that didn't include the
ability to work with negative numbers with the :visible pesudo
selector. This commit adds that ability so you can do:
`table.column("-1:visible")` to always get the right most visible
column
with :name postfix.
- Previously you could use a jQuery selector for columns by using the
:jq postfix, and names were matched otherwise. This is reversed now
for consistency with the rows and cells selectors which treat strings
as jQuery selectors without the :jq postfix.
returned undefined, null etc.
- The base issue was in the instanceof check which has a priority error,
it was:
! obj instanceof _Api
which is the same as:
(! obj) instanceof _Api
which is rubbish.
We want:
! (obj instanceof _Api)
but there is of course a wrapper function, so that needs ot be taken
into account as well. The new logic does just that.
- Because of the manipulation of the initalisation object initialisation
of multiple tables with a single jQuery call (i.e.
`$('.dataTable').dataTable();`) was broken since the second table
would see the modified init object. Need to take a coopy of the object
before entering that state.
- This could probably do with a bit of a clean up sometime...
- The displayLength option is poorly named, particularly with the new
API refering to it as the page length (page.len()) so, using the new
translation option to allow backwards compatiblity while using new
parameter names, I've updated this parameter's name and its
documentation.
- Renaming in keeping with the new terminology
- Updating example which uses it (main documentation still to be
written)
- Backwards compatible with a bit of logic to check if the old version
is being passed in
- Decided that it would be better to provide the new API by having
plug-ins extend it directly, rather than providing their own API.
Using the plugin() method it was possible to get a plug-in insta,ce
for example TableTools, but the way it should work is that TableTools
would provide a tabletools() API method, registering it as an
extension to the DataTables API objects. Further more, TableTools
should provide methods such as row().select() etc, extending the
current API rather than doing its own thing which the plugin() methods
prompted.
- No backwards compatiblity issues here as the plugin() code hasn't
shipped as a release.
- I added a static DataTable.on() method previously in the 1.10
development for a single event called `construct` which would tell us
when a table was constructed. But I've realise that since the events
that DataTables' triggers bubble up through the document, that effect
can already be achieved:
- Use:
- $(document).on( 'init.dt', function ( e, settings ) { } );
- Rather than:
- $.fn.dataTable.on( 'construct', function ( settings ) { } );
- No backwards compatiblity issues as the DataTable.on code was never
shipped, its dev code only
- Previously DataTables would only show an error message if there was a
JSON parsing error. However, if there was any other kind of error,
such as a 404, it would just silently swallow the error. THink its
best to show an error and a tech note.
- This is a breaking backwards incompatible change - please be aware of
this!
- DataTables fires custom events such as `draw` etc, but these events
were in no way identifyable as eminating from DataTables rather than
some other component, which can cause confusion and difficulty
resolving bugs.
- As such, all DataTables events are now fired with the `dt` namespace -
this means if you are currently using events, you must update your
code to also use the .dt namespace. If you are already using
namespaces, that's great, you can continue to do so as jQuery allows
multiple namespaces, but you must still use the .dt namespace.
- This is a breaking change because the old behaviour was incorrect -
i.e. this was a bug to be fixed, hence why we haven't gone through a
deprecation cycle. The old events weren't well documented (only in the
JSDoc generated docs and a few of my forum posts), whereas in 1.10
they will form a key part of the documentation. As such, now is the
time to get this right. This will be documented clearly in the upgrade
notes.
- Discussion on this topic here:
https://github.com/DataTables/DataTables/issues/245
- columns().cache() should check for the parameter 'search' for naming
consistency
- Plural error on column().nodes()
- Change column.index() fromIndex/toIndex to fromData/toData - its an
index be it data or visible, so the old method was meaningless
- The columns() methods have header() and footer() children to get the
header and footer cells for the columns. For naming consistency the
table() methods should be named likewise
- to$ - Convert the result set to a jQuery object. Compliment to the
toArray method. This is mainly useful when working with the node() and
nodes() methods.
- toJQuery - Alias of to$
- join - Array join method
- With the new API the filter() and sort() methods already have meaning
(the array methods built into Javascript) so the methods for filtering
and sorting in the API are called search() and order() respectively.
However, the intialisation parameters and events in DataTables use a
mix of filter, search, sort and order in their terminology so this
commit harmonises on just search and order, updating where
appropriate.
- There are a number of incompatible changes if you are already using
the new options in 1.10, but no incompatible changes to the latest
release (1.9.4). 1.10 changes:
- Server-side processing, the new parameters sent have been updated
to refelect the new terminology
- The Ext object likewise has been updated
- Default with the old options and padding int he old options will still
work as before, compatiblity functions have been added to provide
mapping. If both are provided the new parameter value will take
president.
- The change is primarily around `sort` since that was reasonably
consistent in its terminology for the initlaisation parameters before.
column index referencing of the cells.
- Previously a colspan in a footer cell would cause index misalignment -
for example if you had a table of 6 columns with two in the footer
(one colspan=5) the fotoer cells would be assigned to the first two
columns in the table, breaking column index order. Now a cell can be
used over multiple columns. This allows column().footer() to always
reflect the cell that belongs to that column (possibly sharing it with
other columns).
- Note that the footer will only use cells from the first row in the
footer. If there is more than one row, use table().foot() to access
the TFoot element and then manipulate it as needed.
