Based on DataTables/DataTables/issues/214 this commit uses the optional id parameter for the AMD define function to give DataTables a 'name' for easy referencing.
- DataTables tables previously did not automatically adjust their sizing
when the window width was changed, which let to a lot of additional
calls to fnAdjustColumnSizing in peoples code (and support questions
in the forums). This commit add adjustment to the sizing automatically
for tables width have width="100%" as an attribute (we can't use CSS
since we can't know if it is relative or absolute sizing) - extending
what went before. This has full compatiblity with scrolling and
non-scrolling tables. A throttle is used to not bring IE to its
knees...
- The shim layer call to api.draw() was telling the API to reset the
paging, but it should have been holding it static (as it now does by
passing false in to draw()).
- It is quite common to have a row selection styling in DataTables, so
it makes sense to built this ability directly into the core CSS. It
doesn't add too much extra weight, but it would be a huge pain for
developers to do themselves and also it means I can reuse it in
TableTools / Editor.
- This event allows plug-ins (specifically FixedColumns in this this
case is what I'm thinking of, but others such as FixedHeader could
also benefit) to alter their layout when the column sizing is changed
(for example by a window resize).
- My fix a while back for detecting if a column was no longer available
in a table was duff, since it used $.map which flattens its array
return, but sorting needs a 2D array.
- Fixed by doing our own itteration
- Because of the way _fnExtend() was deep copying objects, but shallow
copying (i.e. references) arrays, the arrays used in the settings
object were actually being shared between all instances of DataTables
on a page.
- This is most noticable in the column filtering, whereby if you apply
a filter to the column of one table, it is applied to all tables!
- The fix is to dump _fnExtend and replace it with a typical jQuery
extend. However, one special consideration is made for the data being
passed it - we absolutely do want that reference to be retained (that
+ the fact that extend is slow on large arrays/objects) so it is
dumped into a temp variable which is then assigned back to the cloned
object.
- This fixed DataTables/DataTables issue #213
- The `settings.aoPreSearchCols` array was being shared between every
table on the table (test using a simple:
$.fn.dataTableSettings[0].aoColumns ===
$.fn.dataTableSettings[1].aoColumns
) which meant that a column filter aplpied to one table would be
applied to all others.
- Fix is to deep copy the search model when adding a columns
- Fixes DataTables/DataTables issue #213
- It is far from uncommon to do `* { box-sizing: border-box; }` at the
top of your CSS these days, including in frameworks, but this could
cause DataTables a little bit of a problem when scrolling both
horizontally and vertically since the padding it adds to the header
linear element to allow it to scroll over the vertical scrollbar would
be folded into the width of the div linear, rather than added to it.
- Fix is to simply set the box-sizing for the linear. I've decided to do
this in Javascript rather than CSS since it is going to be needed
regardless of the CSS being used.
- This commit sees the number of built in type detection and sorting
functions increase to cover the most common cases of use of plug-ins
for DataTables (witht he exception of dates, for which a new first
class plug-in will be created). Specifically, DataTables now has built
in support for:
- Dates (Date.parse())
- Numeric sorting
- Formatted numbers sorting (including currency and thousands
seperators)
- Numbers wrapped in HTML (link tags for example)
- Formatted numbers in HTML
- HTML
Although the numeric sorting plug-ins could have been collapsed down to
just two plug-ins (rather than 4) I decided to do it this way to allow
type based filter formatters to be used with the formatted number types
to allow search for "100,000" or "100000" to match the same data. This
is not built in, but it is possible (and might be in future).
- The goal with these additional functions is to enhance the abilities
of DataTables out of the box to cover the most common cases for data
usage - DataTables is all about making data in tables more accessable
after all! The size cost is ~300 bytes for these additional functions
- In the case of filtering, if there is no filtering extension for the
column type, then the basic string based filter formatting is
performed (i.e. string is always the fallback - there can't be an
error because a function isn't there).
- This commit matches that behaviour in sorting. If you define a column
type as something for which there is no column sorting function, then
the string type will be used rather than resulting in a javascript
error.
- Automatic column type detection was a real weak point of v1.9- - it
did basically work, but if you then updated a row that didn't match
the current data type it would always end up as a string. A good
example of this is the ambiguous date "06-06-13" (is it dd-mm-yy or
mm-dd-yy?). If it was detected as dd-mm-yy and then you add '05-20-13'
to the column (or update an exisiting cell), the type would not match
the exisiting value that thus failover to a string.
- Type detection is now more rigorous, but still optimised (since it
has the potential to take up a significant amount of time). When a row
is added or updated, or a cell is updated, the exisiting type is
removed from the target column(s) and then, before sorting or
filtering, the _fnColumnTypes function checks to see if any column
needs to be type detected and do so if needed. This approach allows
multiple rows to be added (for example) before the draw is performed and
the type actually needs to be calculated.
- In future I'd like to have a 'data-ready' type event which will tell
DataTables, and any of its components that something wants to work with
the data in the table and it should prep the data. The counterpart would be
a 'data-invalid' flag which would be set on update, add etc so it knows
when an update is needed.
- The oApi option wasn't being attached correctly to either the settings
object or the instance, so plug-ins were breaking. This adds the alias
back in.
- If you were multi-column sorting, and didn't have shift depressed and
click on the first column in the sorting priority, the multi-column
sort would be retained. Non-shift click on any of the other columns
would reduce to a single column sort, so match here
- This is a fairly far reaching commit in that the DataTables.ext object
is updated to primarily use camelCase, just like the rest of the 1.10
API. The old notation is still available for compatiblity, but
deprecated.
- While working in this area, I've made a number of updates:
- .model.ext has been removed - that was redundant and not useful.
DataTables.ext is where the plug-ins for DataTables will live and
will be correctly publically documented as such.
- Type based actions (detection, sorting and filter) now live in a
`type` namespace to make it clear that they are type based.
- Internal references to .ext updated to use the new parameters. We
could use the old ones since they are fully backwards compatible,
but I'd rather set the standard by using the modern ones.
- JSDoc comments for .ext updated
- Extension examples updated
- When creating the new visiblity methods, I forgot to have the table do
a scroll draw to have the columns align correctly for the header and
body. This commit fixes that.
- Also update the column visiblity example to use jQuery events rather
than DOM0 events.
- Previously you'd need to use initComplete and columns.adjust() to take
account of the data that was loaded by Ajax. Now this will be done
automatically. It does mean a few more clock cycles, but I think
that's a tradeoff that is worth it.
- Alias the static methods to camelCase and hungarian varients:
- versionCheck()
- tables()
- isDataTable()
- Small updates in styling of the static functions
- I'd previously added columns().cache() which gets the cached
information about filtering or sorting, but this rounds the API off,
extending that also to rows and cells:
- rows().cache()
- row().cache()
- cells().cache()
- cell().cache()
Fix: I've removed the third entry in the aaSorting array, as the issue
was that after using order() that entry wasn't present. It was a bit
confusing as well, so it is now replaced with a property (_idx on the
aaSorting entries) which indicates the current sorting index (in
asSorting) - and this property is optional. If not given, it is looked
up or 0.
build and commit scripts to keep the src and build repos in sync.
Dev: Update the dataTables main file to the latest build which was
accedentally committed. Just a couple of little dev fixes - no API
changes.
- DataTables/DataTables is now going to be a build mirror of
DataTables/DataTableSrc which will host the source core. Scripts will
be used to build the generated files as there will be a number of
these now (examples, JS, CSS, web-site documentation etc).
- Previously there was columns().cells() and column().cells(), but these
were removed in f0a73ce due to the changes for the new top level
cell() and cells() selector methods.
- This commit effectively re-instates those functions but under the
`nodes()` name, matching the row and cell selection options. This is
for completeness in the API.
- Previously the sort classes were being applied at the end of the
_fnSort function, with a callback for when using deferred rendering
and server-side processing (that was a performance hit for deferred
rendering thinging about it, since it hapened twice).
- Now a single callback is used so sorting classes are applied only
after the draw is done.
- Rendering functions can now be provided for the header cells in the
table, which will format HTML in the cells (note only the cells that
are identified as the 'control' cell for the column have the renderer
applied) and apply any classes needed (thus the renderers should
listen for the 'sort' event).
- This is done to provide integration options for other frameworks and
advanced styling controls. For example, FontAwesome could now easily
be used to style a header with sorting icons sourced from the font.
- jQuery UI header rendering has been seperated out into its own
renderer which is activated by the bJQueryUI initialisation option.
This, along with the whole of DataTables' jQuery UI ThemeRoller
support will be moved into a plug-in in 1.11 (it is very tempting make
that change now, but one major version for the decprecated option is
correct I think). This is the last part of the jQuery UI integration
that needed to be decoupled from the DataTables core - it can now all
be provided by plug-ins.
- This fixed issue #153
- Renderers still be to documented.
- Setting `box-sizing: border-box;` for table cells would cause
DataTables to incorrectly calculate the size of the element when
applying the scrolling draw. This is because jQuery's $().width()
always returns the content width (taking into account box-sizing).
- One possible fix was to detect the box model used and switch between
width() and outerWidth(), but a much better fix is to use
$().css('width') as this does take into account the box-model and
allows DataTables to draw the scrolling table columns correctly,
regardless of the box model. It should actually also improve
performance, since jQuery doesn't need to look the box model up
itself.
- This fixes issue #157
can return only objects now.
- The new `ajax` option for 1.10 did previously allow both arrays of
objects with name value pairs and objects, however, this change
removes the option of using arrays of objects to try and simplify
things. One of the most common questions in the forums is about name
value pair objects, so this sidesteps that.
- The big benefit of doing this is that the data passed into `data()` is
now very easy to manipulate. Rather than needing to loop over the
array, you can just modify the parameter you want.
- It also allows an object to be passed back from the function,
manipulated as desired. For example it is now super easy to nest the
DataTables parameters in a sub-object:
$('#example').dataTable( {
'processing': true,
'serverSide': true,
'ajax': {
'url': '../server_side/scripts/server_processing.php',
'data': function ( data ) {
return { 'myprop': data };
}
}
} );
This fixed issue #124.
- The parameters submitted to the server and those expected back are
currently left as is. They will be updated to be camelCase at some
point, but not yet sure if that will be for 1.10 or 1.11.
- Styles weren't being correctly applied becuase the selector was
`table.dataTable.display.stripe` rather than just
`table.dataTable.display` for the "correction" styles when multiple
styles are enabled.
- Reducing the complexity of how the global filter is applied in
DataTables by removing the `asDataSearch` internal settings array
which held information about each row's filtering data. This is now
held on a per row basis in `_sFilterRow` which is built only when the
data is invalidated. This should result in a small performance
improvement as well as simplifying and reducing the code.
- Filtering is now implemented by simply checking the built regex
against the `_sFilterRow` parameter for the display array (with a
reset to master, as there was before, if needed)
- This also fixes an indexing issue that was present in the filtering in
1.10.dev only
