<input> controls used by DataTables for length change and filtering
respectively.
- Bootstrap 3 requires a styling class be set directly on the element,
so in order to correctly support Bootstrap 3, which we want to do, we
need to have the ability to set these classes. This commit adds that
ability
- Because of the decoupling of the filtering and sorting, the filtering
was missing that the indexes of the displayed data will have changed
after a sort. So need to do a full filter when just sorted
styling
- Note that I've included the bootstrap and Foundation integration files
in the resources folder. In future these files will be on the CDN, but
that isn't up and running yet...
- scrollX was often the source of frustration when setting it to
anything other than "100%", which is was in the demos and
documentation but it makes it easy to see that you could set it to be
50% or anything else. That usually broke the developer's layout. So
now you can just use scrollX: true, to enable horizontal scrolling.
The demos have been updated for this.
- A numebr of support requests are about why the layout immediately
after a DataTable looks wrong, and its usually because of the floats
used by info / paging, so we self clear the wrapper around the
DataTable controls
- Updating the build process to introduce the example builder to convert
the XML example files into HTML files. This process is performed for a
number of reasons:
- Much more maintainable - links automatically updated
- Add / remove examples easier
- Modify page styling easier
- Examples can be directly integrated into web-site since they are
transformed by template
- Common data sharing
- Note that the work on the new example build process is not complete in
this commit, there are still a few things to do! css, media paths and
completing the templates.
- Rather than creating a new JSON object from the XHR, use the one that
was returned by the server. This is useful if you manipulate the data
since you want to just keep using the same object.
- The HTML5 attribute detection for sorting, filtering etc was breaking
if you didn't provide a filtering _and_ sorting attributes since they
created an undefined get data function, which causes DataTables to
complain. Fix is to just check for a null value.
- IE10 has a little `x` to clear text boxes which fires the `input`
event, so we need to monitor for that in the filtering input.
- While I'm here, I've also added support for the paste and cut events
to change the filtering when they fire. Via keyboard the fire on
keyup, but not if you use the mouse. They do now.
- Not that it us possible to have multiple events fire (keyup + paste
for example). The logic of checking for a change of input counters
this.
- Thhis fixes DataTables/DataTables issue #227.
- Based on thread 17024 - if you have a large table with a lot of
elements in the tbody, the find('*') selector was of course selecting
them all. That results in poor performance. DataTables doesn't add any
events to the children in the tbody, so we can filter out those
elemetns and keep the element list ot a sensible size.
- Based on the discussion in forum thread 16961 and the results from
http://jsperf.com/html-decode I've updated how the HTML decode for
filtering is done to bypass jQuery and use DOM methods directly. It is
more code but it is also much faster.
- Based on feedback from Rich Caloggero in forum thread 13421 the ARIA
live region DataTables was adding to the TBODY element of the table
have been moved to the table information element, so screen readers
don't go mad announcing the new informaiton in the table on every
change, but rather just read the summary.
- The built in filtering formatters and type detection need to be able
to handle just about any data being passed into them. They were
tripping up with null data being passed in before.
- Based on the discussion in forum thread 16938 DataTables now has the
ability to use _PAGE_ and _PAGES_ in addition to the exisiting
_START_, _END_, _MAX_ and _TOTAL_ options in the information language
strings. This allows the developer to show paging information rather
than record based information in the information element.
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.
