Modified: The 'i' counter that was in the sort loop was outside the function scope, so the JS engine would need to go back up a level in its scope chain. Not a big thing, but any speed in the sorting function is welcome
Dev fix: Oops - committed code from a test to the zero config example!
New: aDataSort parameter for columns - this allows a column's sorting to take multiple columns into account when doing a sort. For example first name / last name columns make sense to do a multi-column sort. Previously in DataTables you would need to have the user do a multi-column sort themselves (with shift), but now you can define aDataSort (for example aDataSort: [ 0, 1 ]) to do effectively a multi column sort. Note that this is not shown to the end user that this was a multi-column sort in the same way that iDataSort wouldn't indicate that it could sort on a different column (if that was configured). Also note that iDataSort is still available for use and has not been modified externally, but if aDataSort is defined it will be given priority over any iDataSort parameter.
New: Optimisation for sorting - when the sorting runs it will execute the sorting function a lot, particularly for large tables, so we want these functions to be as fast as possible. As it stood, each time the function ran it would prep the data and then do the required comparison - and it would do that data prep every time. This is pointless since toLowerCase (for example) is always going to give the same result when using the same input - so now introduced a third sorting function type (in addition to 'asc' and 'desc') called 'pre', which will pre-format the data to be sorted, only once for each item to be sorted, allowing the sorting comparison function itself to be really fast (simply just the comparison). This is also backwards compatible, if the sorting type doesn't have a 'pre'-formatting method then it will just use the two sorting functions as normal.
Fix: Filtering doesn't deal with carriage returns - 6313 - thanks to Jonathan Camp for this fix.
Big change to how DataTables constructed in the file system - breaking the various parts of DataTables seperate files. This is probably the biggest individual change to DataTables since it was first written, but the code itself is more or less the same - just split out into different files. The one big change to the code thus far is to change the function classSettings into an object that is extended. More work is required on this to complete the alteration, but for now DataTables is building into the same workable form as before using the new make.sh file.
Add detailed JSDoc comments for the initialisation options for DataTables
First pass are using $.extend for the settings and initialsation objects.
Back into a state where the zero config will work
Tidy up the constructor to take account of the fact that we now have every possible property in the initalisation objects, since it is being extended from the details - i.e. no need to check for 'undefined' any more.
Add defaults for aDataSort and sServerMethod (the two new parameters that have been introduced since the last release)
Document the row model and update the data methods to extend this model as the base for aoData
Drop "_iId" from the row model - its not used anywhere in DataTables these days. An old legacy property from the 1.3 days I think - can't imagine any third party plug-ins use this property either - its more or less useless these days.
iNextId can go the same way as _iId since that is all it was needed for
Add JSDoc comments for the DataTables column object
Fix various comment spelling mistakes
Add JSDoc comments for the DataTables settings object
Use the oSearch model for the default initialisation and column initialisation
Internal and API methods now use JSDoc comments rather than my old system
Add examples to API methods and tidy up the way oApi is generated a little
This is very certainly 1.9.0.dev now!