- 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.
