[OpenLayers-Users] Methods for status notification when using Strategy.Save with Protocol.HTTP

[Dennis McRitchie]

With OpenLayers v2.12, I am using Strategy.Save along with Protocol.HTTP in a layer, in order to save the user's changes back to the server. I have been able to find how to determine whether the POST/PUT request(s) succeeded or failed, but was unable, at first, to find a way to determine which request(s) failed and what the actual HTTP status code was. The latter was needed to determine the action to take: some codes (set by the server software) should result in the user retrying to save, whereas others should result in the user simply reporting a problem. I was able to finally figure this out by studying the OpenLayers code, and thought I would share what I found on this list.

My initial attempt was:
----------------------------------
saveStrategy = new OpenLayers.Strategy.Save();
saveStrategy.events.register('success', null, saveSuccess);
saveStrategy.events.register('fail', null, saveFail); 

fieldsLayer = new OpenLayers.Layer.Vector(
    "Mapped Fields",
    {
        protocol: new OpenLayers.Protocol.HTTP({
            url: "/afmap/api/postkml",
            format: new OpenLayers.Format.KML({
                foldersName: kmlName
            })
        }),
        strategies: [saveStrategy],
        displayInLayerSwitcher: false
    }
);
map.addLayer(fieldsLayer);
.
.
.
// event.response is the final response object. event.response.reqFeatures is a list of all the layer features.
function saveSuccess(event) {
    alert('Your mapped field(s) have been successfully saved.');
}
function saveFail(event) {
    alert('Error! Your changes could not be saved. ');
}
----------------------------------

But in the case where saveFail is called, the final response object contains no information regarding which features were saved, which were not, and what the HTTP status code was. To get this information, one has to enable user-callbacks for the HTTP requests themselves (via the Protocol.HTTP, rather than via Strategy.Save. To do this, then after creating the layer of which Protocol.HTTP is a part, define the following:
----------------------------------
fieldsLayer.protocol.options.create = { callback: saveCreateFail, scope: this };
fieldsLayer.protocol.options.update = { callback: saveUpdateFail, scope: this };
fieldsLayer.protocol.options.delete = { callback: saveDeleteFail, scope: this };
.
.
.
function saveCreateFail(response){
    alert("saveCreateFail called: code: " + response.priv.status);
}
function saveUpdateFail(response){
    alert("saveUpdateFail called!");
}
function saveDeleteFail(response){
    alert("saveDeleteFail called!");
}
----------------------------------

Note that in this case, the response object is passed directly as an argument to the callback. There are three callback types, to handle the case of new features, features read from the server and modified, and features read from the server and deleted, respectively. Note that the update and delete callback functions are called once for every feature; whereas the create callback function is called once for all new features. Here is what you now get:

1) the list of features being reported on is to be found in response.reqFeatures.
2) the success/fail status of the POST/PUT is in response.code, which contains OpenLayers.Protocol.Response.SUCCESS or OpenLayers.Protocol.Response.FAILURE.
3) the request type ("create", "update", or "delete") can be found in response.requestType, which would allow you to have one callback function process all three request types.
4) the HTTP request object is to be found in response.priv, so the HTTP status code is in response.priv.status, and the status string is in response.priv.statusText.

Note that the fact that the request object is in a field called 'priv' suggests that this is an internal field and is presumably subject to change. But as far as I can tell, in v2.12, it is the only way to access this information. So if you stick with 2.12, your application will keep working. But it would be nice if this info were available as a documented field of the Response object.

Hope this helps.

Dennis

Dennis McRitchie
Computational Science and Engineering Support (CSES)
Academic Services Department
Office of Information Technology
Princeton University