Since: Editor 1.0

Ajax configuration for form data submission. Please note - this property requires the Editor extension for DataTables.

The full Editor reference documentation is available to registered users of Editor - the information shown below is a summary only. If you already have an Editor license please , alternatively an Editor license can be purchased on this site, or sign up for the free trial.


Editor will read the data that it is to edit directly from a DataTable, or HTML elements if used in standalone mode, but that edited data needs to be sent somewhere so it can be saved for later retrieval. This option defines the actions Editor will take for submitting the data to be stored when submit() is called.

ajax can take a number of forms, documented above, to make it easy to configure where and how Editor will send the data for your specific use cases. It can even be given as a function to allow complete flexibility. It is very much based on the DataTables ajax option and the two are very similar in operation.

URL parameters

The URL given as the Ajax submit address using this option (either as a string, or in the url option of an object) can contain the following options which will be processed and automatically replaced by Editor:

  • _id_ - Will be replaced by the row id that is being edited or removed (as defined by idSrc). If multiple rows are being operated on, the ids will be joined as a comma separated list. This can be particularly useful for REST services - for example /staff/_id_ might be submitted as /staff/4 for staff entity 4 on edit / remove. Note: the _id_ is a literal string and will be automatically replaced by Editor. See the examples below to see how it might be used.

Server response

The data submitted by Editor and that expected in return is documented in the manual. The Ajax options discussed on this page are basically a transport layer to facilitate that data interchange.

The request to the server will be considered to be successful as long as valid JSON is returned (regardless of status code), while any response with invalid JSON will fall into Editor's error handler. This is particularly useful when interfacing Editor with an REST service where response codes can be used to convey useful information - for example a submission which contains invalid data could have a 400 response code and valid JSON noting which field was in error, and what the error was. Editor will correctly handle such a case.

Backwards compatibility notes:

  • The functionality of this option in Editor 1.3 replaces the deprecated ajaxUrl. More specifically, with the addition of the ability of this option to be given as a string in 1.3, ajaxUrl is redundant.
  • URLs given in this option (either as a string, or in the url option of an object) can be prefixed with an HTTP method followed by a space and then the URL (for example PUT /data). This is provided for full compatibility with the old ajaxUrl option, but it is recommended in 1.3+ to use an object structure with the type option set (see examples below).