- 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
for the header cells (matching the standard case, in addition to the
ui-state-default class for styling).
- This allows the developer to add styling information based on the
sorting state of the cell.
- This fixed issue #17
- When using _pluck with deferred rendering, there were a number of
errors due to the nTr element being undefined (that's what deferred
rendering is all about of course). So the logic to check that pluck
can pluck from a source object needs ot be added.
object
- Previously to modify the class names that DataTables uses for its
components you has to use $.fn.dataTable.ext.oStdClasses. Now you can
use the `classes` initialisation option which will extend the classes
object of the DataTable.
- This fixes issue #180.
- Building on the new ability of DataTables to work with element
attributes as data sources for sorting and filtering, this commit adds
auto-detection of the attributes 'data-sort' and 'data-filter' in DOM
sourced tables.
- The first row in the table is used for this auto-detection and the
built mData object assigned only when it is found to be the default
for the column (i.e. the column index). So any custom value is
retained and thus if you want to use a custom value you need to build
the attribute querying object manually (I think the majority of uses
will not need this!).
source orthogonal data for filtering, sorting and type detection data.
- In HTML5 the data-* attributes can be used to add semantic data to an
HTML page, which a user will not see, but the scripts on the page can
interact with. DataTables now has the ability to use these attributes
(actually any attribute can be used) as a data source. Previously DOM
sourced tables always used just the content of the cells for all data
interaction, but this can provide advanced controls in just the same
way that Javascript / Ajax sourced data can do orthogonal data in
DataTables.
- A typical use case is to provide numeric sorting information for
complex formatted dates that the browser doesn't understand with
Date.prase().
- The SCSS stylesheet is now feature complete, and the
jquery.dataTables.css file found in the repo is now directly generated
from that SCSS file. The SCSS online compiler will run the stylesheet:
http://sass-lang.com/try.html .
New: SCSS base stylesheet with variables for colours
New: Pagination styling
- DataTables now has the ability to selectively enable different style
types by applying different class names to the host table. The options
supported are:
- hover - show a hover effect over rows
- stripe - show odd/even row stripes
- row-border - show a vertical border between rows
- cell-border - show a border around all four sides of a row (only
one of row-border or cell-border should be used)
- sort-column - highlighting of the sorting column.
I will be adding another class along the lines of `display` which will
enable 'hover, stripe, row-border and sort-column' (although this is
not yet implemented).
The reason for doing this is to encorage developers to style their
DataTables more their own way, but making it easier to enable the
features they want.
- To that end, the DataTables stylesheet will be generated from a SCSS
template in future. The SCSS template is included in this comment
(although the generated stylesheet is not yet committed). This allows
colours to be changed which a trivial amount of effort, while still
being able to get row highlighting etc, thanks to SCSS's colour
functions.
- Pagination styles have been updated to fit in with the new styling of
the DataTable.
flexible and simple to actually use.
New: Two additional built-in pagination types: 'simple_numbers' and
'full'.
Update: 'two_buttons' type pagination (previous default) renamed to
'simple'.
New: Default pagination type is now 'simple_numbers'.
New: Introducing renderers to DataTables (something that will play an
important part moving forward).
New: Simplified pagination button classes to simply:
* "sPageButton": "paginate_button"
* "sPageButtonActive": "current"
* "sPageButtonDisabled": "disabled"
- The basis for this commit is a restructuring of how pagination
plug-ins work in DataTables, whereby the pagination plug-in simply
returns an array of button types which should be shown. These are then
actually displayed by the renderer. This seperates the logic for which
buttons to show from the display logic, making it much easier, both to
customise which buttons will be shown, and for integration plug-ins to
customise the display of the buttons (since they don't need to
replicate the button calculation logic). This change allows us to
introduce two new built-in pagination types to DataTables with minimal
size cost. Indeed, this change as a whole reduces the compressed
DataTables size by 2.5K (additional functionality, simpler and smaller
- what's not to like!?).
- Pagination button classes in DataTables were a mess before, with
different classes used for the two built in types, with the additional
complexity of only one of the defined class options being used, rather
than concatinating the classes based on the type. This was bonkers and
a barrier to new users styling the form as they wanted. Reducing to
just three class options, and having the active and disabled options
added to the base class makes it MUCH simpiler. This could hit
backwards compatiblity for those who had styled the mad old style, but
it would have been crazy to keep it while writing the rest.
- If a row has been invalidated, then we need to perform a full
re-filter, so we need to pass this invalidation information back up
from the invalidation checker to the filtering functions.
- If the number of columns in the table were reduced, then the column
filter state that was saved would be incorrect since it would define
more columns that there were. Equally sorting could potentially be
done on a column that no longer exists.
- There were a few work around in the code already to try and address
this a bit, bit not satisfactorily as seen by thread 14114. The real
issue was that the columns were being detected after the state was
being loaded - ideally we want to load state after the columns had
been detected and throw away the state saved if the columns did not
match since the table might be entirly different.
- This is done by a little bit of reordering in the constructor, and
actually simplifies the code a bit.
- I had inadvertantly broken the ability to set an initial draw position
using `displayStart` or state saving with the small refactoring of
_fnDraw and fnDisplayEnd. fnDisplayEnd must be called with
settings._iDisplayStart set, which is now done simply by changing the
order of calling a little.
property
- Extending the funtionality of DT_RowId and DT_RowClass, this commit
adds DT_RowData which utalises jQuery's `$().data()` method to set
HTML5 data-* attributes, which can be useful for additional meta data.
- This is some what complimentary to using objects as the data source
where you could just use row().data() to get the data, but this is
effectively an orthogonal way of getting the data and might be useful
for existing Javascript libraries.
- It should be noted that the data-sort and data-filter work I'll be
doing for v1.10 shortly will not interact with this method, that will
be DOM sourced data only, while this is Ajax / Javascript based only.
However, if you do want to use data from this source for filtering /
sorting, its easy to do with `data` - `data: 'DT_RowData.sort'` for
example.
- This fixes issue #45.
- Had split the row details out into its own file a little while back,
since it is 100% self contained now, but hadn't committed the file!
Here is it now.
errors
- A lot of posts in the forum are questions such as "what does the
invalid JSON response" error mean, or "how to fix the unknown
requested parameter error". To address these, rather than having them
answered individually in the forum, I'm going to write a series of
technical notes for DataTables (getting started, how to use columns
etc) and as part of those, each error that DataTables can fire off
will have a technical note explaining in deatil what the error means.
- Example:
DataTables warning: table id=example - Invalid JSON response. For
more information about this error, please see
http://datatables.net/tn/1
- This commit puts the required logic in place. The technical notes
don't exist yet, but they will soon. They will be:
1 - Invalid JSON response
2 - Non-table node initialisation ({this.nodeName})
3 - Cannot reinitialise DataTable
4 - Requested unknown parameter {param} for row {idx}
5 - Unknown paging action: {action}
6 - Possible column misalignment
- The table cannot fit into the current element which
will cause column
- This also has the advantage that the errors in the DataTables code can
be a little smaller. Around 500 bytes saved.
- This fixes issue #173
non-array element
- If found to be something other than an array, it will treat it as if
it were an array with a single element in it, of the value given.
- With the new API that is being introduced in v1.10, the old API
(fnUpdate, fnAddData etc) is being deprecated and retired. It is now a
shim layer calling through the new API, rather than duplicating the
logic of the calls, but is still provided for backwards compatiblity.
- It is _strongly_ recommended that you start to use the new API from
this point in - very certainly for new projects.
- The api() method, is not deprecated, it is new in 1.10 and provides a
way to get access to a DataTables API instance from the jQuery host
object, if the table is initlaised with `dataTable()` (rather than
`DataTable()` which does give you the API instance. It has a single
option which is used by the old API's shim layer to allow it to use
the iApiIndex option to get the context to be used.
- There were two functions called _fnGetRowData, which were conflicting
- The $().map doesn't execute with the scope of the element, need to
pass the element through to the get data function correctly.
- The row()/rows() methods have index methods, so it makes sense that
the column(s) and cell(s) methods also have index methods to get the
raw information out of the table. Rather than shying away from the
indexes in 1.10, as has been done with the pervious versions of
DataTables, 1.10 will embrase them as first class citizens.
- New methods:
- columns().index()
- column().index()
- cells().index()
- cell().index()
- It is possible at the moment to use rows().data() to get the data for
the table, you can use rows().data( { order: 'index' } ); to get the
data in index order - I suspect a reasonably common use when working
with the data set (at least, I use it that way!) and its a but clumsy
to write that way, particularly compared to the old fnGetData method.
So the new data() method is a short cut for `rows().data( { order:
'index' } ).flatten()` to get the data set for the host table(s).
- For consistency and completeness, the cell() and cells() methods now
accept their own cell selector option (rather than just rows and
columns) which is a jQuery selector, or no selector at all for all
cells. Additionally it allows an options object to be passed in, to
allow configuraiton of the order of data etc.
- The cells() method now has these calling options:
- cells() - all cells
- cells( opts ) - option configuration
- cells( selector ) - cell selector
- cells( selector, opts ) - cell selector + options
- cells( rowSelector, columnSelector ) - row + column selector
- cells( rowSelector, columnSelector, opts ) - row + column selector +
opttions
- The cell() method as the same signature.
with newly added rows
- Looking at fnAddData, and about to replace it, I realised that
fnAddData returned the indexes of the newly added row while the new
methods didn't. It makes sense for row.add() to return a row()
extended object with the newly added rows so row().node() etc can be
used. Also the indexes are in the inst, so that information is also
available. Likewise is done for its plural counterpart.
- Did consider creating an `augment` static method for the API, and
might yet do this, but this is the only place to use it at the moment.
Possibly it might be useful for plug-ins, but before adding, lets see
how the new API is used.
with plurality
- There are four groupings of plural / singular methods in the new API:
table(s), row(s), column(s) and cell(s). We need to provide similar
methods for each, often leading to code duplication. To help reduce
this code duplication I've created a new `registerPlural` method which
allows both the singular and plural to be derived from a single
function automatically. The plural form is given and wrapped up by a
container function which extracts a singular return.
- Note that not all singular methods can use this approach, for example
row().data() provides extra functionality over rows().data() in that
it can be used as a setter as well as getter.
- To round off the API, this commit adds a column() method, for working
with a single column, as with row/rows, cell/cells and table/tables.
- New methods:
- column() - Column selector
- column().data() - Get column data
- column().header() - Get the column header cell
- column().visible( set ) - Get / set the column visiblity
- column().order( dir ) - Order the table by this column
- Note that I haven't implemented column().search() yet as I'm sure
there must be a better way of dealing with the singular functions...
Need to look at the four groups a bit more before this (and then the
API :-) ) is finalised
- The columns().data() method was flattening the returned array. While
possibly okay on its own, that doesn't match the behaviour of how
rows().data() works, where each row is an entry in the array, rather
than the array being flattened. As such I've changed columns().data()
to work work in the say way, for each column you select, you get an
entry in the api instance - an array with the data for the that
column.
- To allow for hte fact that some may want to work with the flattened
data, I've added a `flatten()` method to the instance base, which is
basically a shortcut call to `reduce`.
- Now that we have the cells() / cell() methods, with the ability to
select based on column and row, and the ability to get the whole row
or column cells, the TD get methods on row / rows / columns were
redundant and I think should be removed for berevity. It could also
get confusing with the chaining since there are nested and top level
methods with the same name.
- Removed:
- rows().cells()
- row().cells()
- columns().cells()
- New API methods:
- cell().invalidate() - Invalidate a single cell
- cells().invalidate() - Invalidate multiple cells
- Note that the invalidation is actually row based, rather than cell
based - i.e. the whole row is invalidated. This may change in future
versions of DataTables, but I'm concerned that it would add a lot of
code for little enhancement.
- New API methods:
- cells( rowSelector, columnSelector, opts ) - Cell selector
- cells( ... ).nodes() - Get the nodes for the selected cells
- cells( ... ).data() - Get the data for the selected cells
- cell( rowSelector, columnSelector, opts ) - Single cell selector
- cell( ... ).node() - Get the cell node
- cell( ... ).data() - Get the cell data
- There was a bug in `_selector_first` whereby it wasn't correctly
reducing the set - was gatting away with it before, because it was
reducing to a single element array, which has a toString() method
which allowed it to appear to work for integers.
- New API methods:
- table() - select a single table
- table().node() - get the table node for the table
- To be honest, these methods are not likely to be used particuarly
often, so I think they are fairly low priority, but they could provide
useful, and it is a public way to get the table node.
- New API methods:
- rows().invalidate() - Invalidate the matched rows
- row().invalidate() - Invalidate the matched row
- row().data( set ) - Set the data to use for the matched row
- This involves building upon the invalidation work done in the last few
commits and creating an invalidation function. This new function will
mark the cached data as invalid for re-reading by the sort and
filtering methods (this will need to be abstracted into modules in
1.11, but there is no infrastructure for that yet - that's what 1.11
is all about). Additionally the invalidation method will update either
the data held by DataTables (read from the DOM), or update the DOM if
the data source was not the DOM. A flag allows an override to state
the direction, although I think that generally speaking you might not
want to use the override (you might nuke parts of your data source
object if you read from the dom for example).
- Like sorting, for the new API we need to be able to invalidate data
held for filtering in a fairly simple manner (it could be done before,
but it was messy, see fnUpdate - you need to call the methods in the
parent function, rather than just invalidating). This commit adds that
ability to DataTables.
- Performance improvements:
- The big one is that filtering data is only obtained and formatted
when invalidated, rather than every full filter now.
- Regular expressions for newline and HTML matching are variables,
rather than redefined on every call.
- DIV for reading text version of an HTML formatted string is a
variable, rather than being recreated on every call.
- Type based formatters have been moved into the extension API ('string'
and 'html'). They can be overridden there if wanted. Allows
simplication of the call for the formatter.
- Fixes issue #158 as part of the refactoring.
- Smaller by 22 bytes (compressed)... Likely once invalidation is fully
implemented that will be swallowed up...
- Refactoring _fnSortingClasses to be more efficient in how it operates
and to compress better. This is done by looping first over the
elements to have their classes removed, and then looping over only
those to have them added. Previous all columns were operated upon.
Also using _pluck and that fact that all cells fromt he tbody are
stored makes the code much smaller, more readable and compressable.
Only 0.5KiB saved in the refactor, but every little helps...
- Restored column sorting classes functionality that had been disabled
earlier in the 1.10 development sequence.
- Think this code was in DataTables 1.0 and has been relatively
untouched! A refactor allows it to be more readable and smaller when
compressed (about 450 bytes saved)
- invalidation is going to play an important part in the new API, with
the ability to invalid the cached data for sorting, filtering, display
etc so we need to be able tos upport this in the core.
- In fairness the sorting didn't actually need invalidation because it
would always get data on every sort, which is bad for performance -
proper invalidation and caching will resolve this. Which is what has
been implemented here.
- I had expected (hoped) to be able to save a bit of space in the
refactor, but only aorund 100 bytes (compressed) saved, which will
probably be lost when the invalidation is fully implemented in the
API. Still, better performance, tidier code, and no extra space...
Fix: Sorting classes now show multi column sorting when a column is
defined to sort over multiple columns (sortData). Previously it would
only show the first column.
