simple() static method which makes it very easy to make a server-side
processing request.
- In the examples the SQL statements are all basically the same, so
having this method to wrap them into a single function cal absolutely
makes sense.
- Also added a `formatter` option to the columns array which will format
the data as needed using a closure function.
- Renaming in keeping with the new terminology
- Updating example which uses it (main documentation still to be
written)
- Backwards compatible with a bit of logic to check if the old version
is being passed in
- 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.
- 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).
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().
- 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...!
