In this chapter you'll get all the information about ui-related DataProcessor: its initialization, implementation, usage etc.
To detect data changes on client-side, DataProcessor uses data-changing events. With their help it can detect if item was inserted, updated or deleted.
After DataProcessor knew about changes, it sends request on server to save updated information to database.
Request contains operation's status and item's id for every item.
Server's response contains operation's status (confirmation that an operation was completed successfully or some error occurred), an old item's id and a new item's id (item's id can be changed after some operations on server).
To use DataProcessor functionality in your app you just need to create its object.
DataProcessor constructor is the following:
dp = new dhx.DataProcessor({
url: "products_connector.php",
store: products,
autoupdate: true,
mpde: "post"
});
url - a path to the file which will get data changing requests. In other words, a path to server (if you use dhtmlxConnector, a path to its file can be set as this parameter. In this case, dhtmlxConnector will do all the server work).
store - GlobalStore or dhtmlxGlobalStore object which changes will be detected
autoupdate - if this option is true, then after every data updating dataprocessor will send request to server. Otherwise, updates will be sent to server just after the save() method calling
mode - ”post” or ”get” (for dhtmlxConnector you should use ”post” mode)
For detecting data changes on client-side DataProcessor uses a number of events. For attaching an event, the following method is used:
dp.attachEvent(event_name, callback);
Callback functions are differ for events. See the appropriate callback function under an event (if callback function suits for several events, it's placed under all of them).
if callback returns false, request won't be sent (if there are more then one updated items only the current item changes won't be sent)
if callback returns true it will send data without some changes
if callback returns data hash, this data will be used to update data on server-side
So, you can attach the following events:
onBeforeUpdate - occurs before sending request with status “updated”
onBeforeInsert - occurs before sending request with status “inserted”
onBeforeDelete - occurs before sending request with status “deleted”
my_callback(id, data) {
...
}
my_callback(updates) {
...
}
where updates - a list of updates
update = {
id: "some_id",
data: { hash of data },
operation: "updated||inserted||deleted"
}
my_callback(updates) {
...
}
where updates - a list of updates
update = {
sid: "sid",
tid: "tid",
data: { hash of data },
operation: "status"
}
onAfterUpdate - occurs after getting response from server with status “updated”
onAfterInsert - occurs after getting response from server with status “inserted”
onAfterDelete - occurs after getting response from server with status “deleted”
onError - occurs after getting response from server with status “error”
onInvalid - occurs after getting response from server with status “invalid”
onMyStatus - a custom event. If you specified your own status on server-side and it returns response with status=“MyStatus” - use an event onMyStatus.
function my_callback(sid, tid, data) {
...
}
If callback returns false, id changes aren't applied on client-side (please note, it doesn't block data saving because the operation is already completed)
save() - sends request on server-side for saving all updates of all items
save(id) - sends request for saving all updates for item with specified id (usually if autoupdate - false)
update(id) - sends request to updating item with specified id from server