In this chapter we consider most popular tasks & errors you can face during the development process.
There are two events which can be used to catch the finish of data sync operation:
dp.attachEvent("onAfterUpdateFinish",function(){
alert("single row updated")
});
dp.attachEvent("onFullSync",function(){
alert("all rows updated")
});
At any time the update state can be checked as follows:
dp.getSyncState();
which will return true if all data is synced by the server and false otherwise.
DataProcessor detects a row changing only by the edit operations. If a row was changed by a direct API calling, it will not be updated. In such case you can manually call the dataProcessor to inform about the update operation:
grid.cells(id,ind).setValue(new_one);
dp.setUpdated(id,true);
The row can be marked as "not updated" in the same manner (may be useful in some scenarios):
dp.setUpdated(id,false);
If you want to mark a row with the status different from "updated" (not sure how it can be useful, but still) it can be done as shown below:
dp.setUpdated(id,true,"status name");
Starting from version 2.1, dataProcessor has a default reaction on the "error" response type which is used to report about server-side errors. The row marked as error will be highlighted in the grid. And it will not be sent back to the server until one of the following events occurs:
1. A user edits data in a row;
2. Rows set back to the updated status through the setUpdated command.
It's a reaction on the "invalid" status in the server-side response. It's similar to "error", but has a different visual marking.
If you want to extend it, you should do the following on the client side:
dp.defineAction("invalid",function(response){
var message = response.getAttribute("message");
alert(message);
return true;
})
And you need to do some work on the server-side (if the data isn't valid, a text message will be returned):
<?xml version="1.0" encoding="UTF-8"?>
<data>
<action sid="{gr_id}" type="invalid" message="Data in the first column is not valid" />
</data>
It's possible to extend the default after-update reaction as:
dp.defineAction("updated",function(response){
var sid = response.getAttribute("sid");
var extra = response.getAttribute("extra");
this.obj.cells(sid,0).setValue(extra);
return true;
})
With such a code you will be able to specify any additional data which needs to be updated in the grid after receiving XML response from the server:
<data>
<action sid="{gr_id}" type="updated" tid="{gr_id}" extra="new value for first column" />
</data>
In the case of grid, if you'd like to send some extra data in addition to those, that were sent through the dp.sendData() command, you can use the method setUserData() (sets global userdata for a grid).
myGrid.setUserData("", "some", "value");
On the server side you can get the sent data through the onBeforeUpdate event:
dp.attachEvent("onBeforeUpdate",function(id,action){
action.get_value(some);
return true;
})
Also it's possible to include any custom parameters directly into dataprocessor's URL used in the client-side dataProcessor constructor:
var dp = new DataProcessor("some.php?field="+field_name);
//on server-side for all calls you will have:
//$_GET['field']
If you update data 'partially', you can face the problem when only the first part is updated. For example, you have 3 columns in a grid and want to update some record. At first, you update the first cell. It's updated correctly. You try to update the second and the third ones but they won't do. The following technique will help you to update the 2 last cells:
cells(rId, 2).setValue(age);
cells(rId, 2).cell.wasChanged = true;//added
cells(rId, 3).setValue(gender);
cells(rId, 3).cell.wasChanged = true;//added
To change the URL of the dataprocessor after it's been initialized you can use the following code:
dp.serverProcessor = "some_new_url";
Currently, there is no way to detach dataprocessor from an object. But you can use this technique and reset its URL.
The most probable cause is some server-side error which breaks the XML. You can enable the debug console and check the response of the server side to receive more information (debug console can detect many types of xml-related errors and show the reasons of these problems).
Actually it is not an error - the rows will be removed only after synchronizing with the server. You can define a custom marking routine which will hide rows instead of striking them through.
The most probable cause is the incorrect values of the "action" attribute in the response XML.
Most probably this error is caused by incorrect values of the "sid" and "tid" attributes in the response XML.
Back to top