…xample so it works over https
Dev: Moving on to 1.10.5-dev
Hi! When installing DataTables from the repo with npm >v1.2.20, it'll WARN "No repository field." This small patch resolves that. (See https://www.npmjs.org/doc/files/package.json.html#repository or https://stackoverflow.com/questions/16827858/npm-warn-package-json-no-repository-field.) I hope it's ok to propose this change against DataTables/DataTables -- I couldn't find a `package.json` in DataTablesSrc. Thank you for your work!! M
…dCell` * Based on discussion in thre 22009
part of the build process.
… numbers to be compatible with semver (http://semver.org/). The impact is minimal (unless you are parsing the version for the final part in dev builds). The change is to use a dash ('-') at the end of the version string for a non-release build, rather than a dot.
…ons is now camel case parameters rather than the Hungarian notation that was used before. There are a number of reasons for doing this, the primary one being that the Hungarian notation used by DataTables is actively stopping people from using the library due to their aversion to using Hungarian notation. Without doubt the Hungarian notation used was a mistake (the reason it was used was that when DataTables was originally written, the company I worked for at the time required the use of Hungarian notation, and thus I was trained in it...). 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...!