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 sign-in, 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.
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/4for 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.
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.
- 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,
- URLs given in this option (either as a string, or in the
urloption 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
ajaxUrloption, but it is recommended in 1.3+ to use an object structure with the
typeoption set (see examples below).