- Showing and hiding details about a row in a child row is very useful
and proven to be a popular part of DataTables. This commit provides
that ability in the new API and extends it. It also fully modularises
the child rows aspects, so it could be removed from the core without
effecting any other aspects (it may be moved into a seperate file in
future).
- This will effectively replace fnOpen, fnClose and fnIsOpen
- Added methods:
- row( selector, opts ).child()
- row( selector, opts ).child( str, class )
- row( selector, opts ).child( str, class ).show()
- row( selector, opts ).child( str, class ).hide()
- row( selector, opts ).child.show()
- row( selector, opts ).child.hide()
- row( selector, opts ).child.isShown()
- Note that unlike the old API you need to specify the data first, and
then use the show() method to show the child row. This allows the
details rows to be configured before they are actually shown.
- Additionally multiple child rows can be attached to a parent (pass
`str` (from above) as an array to use this feature. API plug-ins could
use this ability to show fully nested tables.
- Not just a string can be passed in now, but also a TR node which will
actually be used (rather than put into a nested row), any other type
of node (which will be inserted into a wrapper row/cell) or a jQuery
object.
- Cope with the change in jQuery 1.9 for element ordering. From the
DataTables thread on this topic ( 14316 ):
So a bit of further investigation into this - I've used these two test
caseS:
No DataTables: http://live.datatables.net/uwidel/edit#source
DataTables: http://live.datatables.net/ivojev/4/edit
The new DataTables version shows that jQuery 1.9 is now always trying to
order the nodes by document order, not but the order that they are found
in the source array. Additionally removed nodes are appended to the
results, themselves in reserve order, but that's just the way the Sizzle
node ordering works when items are not in the document (try sorting
numbers and you get the same result).
Given the suggestion in the release notes that the move is to have nodes
always treated in document order, I don't think this is a bug, so not
filing one. It is a bit frustrating that the nodes are iterated in a
different order from the source array, but it is expected from their
documentation and comments. So this is simply something we'll need to
work around.
To that end, I've updated the examples and taken the unusual step of
updating the examples on this site outside the normal release cycle. The
examples in the 1.9.4 current release of DataTables can't change of
course, but the updated examples will be in 1.10 when it is released.
- Note that this update is not complete, just the initialisation is
done. The examples will shortly be rewritten to be more modular when
this will be completed (i.e. the code shown on the page will be
updated)
- Rather than using Javascript to show a placeholder, use the HTML5
`placeholder` attribute. That is what it is there for and is supported
by all current shipping browsers (IE9- do not support it, but will not
break)
minor improvement: calculate index based on the element's parent th.
this is better because it allows to have some columns that are not searchable (like when the first row is a checkbox row)
Backwards compatibility issues: The main goal here (other than to use camel-case notation!) is to preserve backwards compatibility. Unfortunately this isn't 100% possible:
- DataTable.defaults.columns has been renamed to be DataTable.defaults.column
- Otherwise it conflicts with aoColumns in the defaults.
Without doubt this is going to be a long process - for example the unit tests and examples need to be completely updated for this change. The JSDoc comments have been updated, so the site should take care of itself for the most part, when released.
In terms of implementation, it is important to note that I have not broken backwards compatibility here - the way it is does is that the current defaults are retained, and a camel-case to Hungarian mapping is automatically generated and then applied to the objects given by the end user. This adds around 0.5K to the size of DataTables, but writing the mapping manually would require at least 3K, and changing DataTables wholesale to camel-case would utterly break backwards compatibility. This is the least 'evil' way to accomplish this. It is important to note that this is a step along the roadmap for DataTables - come v2 Hungarian notation will likely be dropped completely.
One important note to make about this mapping is that if you use camel-case DataTables will copy the value from the camel-case properties to their Hungarian counterparts, so you will end up with additional properties on your source object. As I say, this appears to be to be the least 'evil' option, although still not perfect itself. The challenges of working with legacy software and installs...!
New: Static API method - fnIsDataTable - check if a TABLE node is a DataTable or not
New: Static API method - fnTables - get the DataTables that are initialised on the table (optionally limit to just the visible tables)
Examples update - Tabs and scrolling updated to use the new static fnTables method
Fix: Settings object model was missing the nScrollHead and nScrollFoot properties from the documentation
New: New init option fnCreatedRow - very similar to fnCreatedCell but in this case used for TR elements
Updated: fnCreatedCell now also gets the column index passed in
Update: fnRowCallback - no need to return the TR element - it was a fairly pointless thing to do - if you want to replace the element then you need to do it with fnDrawCallback
