DHTMLX Touch documentation

DataProcessor

In this chapter you'll get all the information about ui-related DataProcessor: its initialization, implementation, usage etc.

Main operation principles

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.

Initialization

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)

Event handling

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);
  • event_name - the name of the event
  • callback - callback function.

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) {
...
}
  • onBeforeProcessing - occurs before sending request (for all updates). Occurs after onBeforeUpdate, onBeforeInsert and onBeforeDelete events
my_callback(updates) {
...	
}

where updates - a list of updates

update = {
	id: "some_id",
	data: { hash of data },
	operation: "updated||inserted||deleted"
}
  • onAfterProcessing - occurs after getting response from server for any status
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) {
...
}
  • sid - an old id
  • tid - a new id
  • data - hash of the item data (empty for deleted status)

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)

  • onUpdated - occurs after updating item (or items after live_update) from server by update() method.

API methods

  • 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