* In IE8 if the DataTables width calculation functions were being
triggered DataTables would clone the table node and then do a jQuery
$().remove() on the cloned node. This was bad in IE8 as it meant that
on the remove the events that were attached tot he original table were
removed as well as the ones on the clone table. IE8 must retain some
kind of link between the original and clone nodes. Using jQuery's
clone() method resolves this.
* See thread 21040 for more information
- The stateDuration option has been updated to provide the ability to
indicate if sessionStorage should be used rather than localStorage
(set value to -1).
- Settings stateDuration to 0 also indicates that the duration is
infinity.
- Parts of the state saving have been optimised for code size, so this
commit actually reduces the min size by 32 bytes despite the new
abilities.
- See thread 19572 for discussion on this
DataTables which character is used as a decimal place in the table's
data, so that number which are formatted using characters other than a
dot as the decimal place can be correctly detected and sorted.
- A large part of the world uses the comma as a decimal place, so it
makes sense to have this option built-in directly to DataTables,
rather than needing to use plu-in sorting types as before:
http://en.wikipedia.org/wiki/Decimal_mark
- However, the decimal place character cannot be detected automatically
since there are far to many ambiguities. As such, a new
`language.decimal` option is defined which is passed through to the
type detection functions. The type detection functions can then use
that character to alter their detection functions to transform numbers
into the dot formatted equivilent for parsing in Javascript.
- The numeric sorting methods have been bundled together in the function
`_addNumericSort` which is called when a character is given for the
decimal mark, adding the sorting functions required specifically for
that mark. This means that any character at all can be added, while
keeping the table's sort performance as it was.
- Code size in increased a little for this new feature, but a lot of
work has been done to keep it to a minimum (while still optimising for
the most common use case of a dot decimal place), and this is a good
feature to have in DataTables' core code.
- All required documentation added and updated.
- Special thanks to Tobias Bäthge for suggesting and sponsoring this
feature.
- Added new orthogonal data example
- Updated columns.data and columns.render documentation
- Reordering the manual a little
- Add note to the old orthogonal data blog post to direct people to the
new manual page
- The jQueryUI option is depricated in 1.10 and will be removed in 1.11
to be replaced by style integration files int he same way that
Bootstrap and Foundation use. This helps to reduce the size of the
core for a feature that is no longer used that often, while also
ensureing that DataTables remains modular and supports many styling
libraries.
- As a result of this change, I want developers to be able to implement
1.10 without needing to use a depricated option, so this highlights
the newly added jQuery styling integration files from the plug-ins
repo.
- 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().
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...!
