On Sunday, May 2, 2010, Stephen Woodbridge <wood...@swoodbridge.com> wrote:
> Hi Devs,
>
> I have been working with OL.Protocol.HTTP and I think I have identified
> a bug in the code after spending considerable time reading and tracing
> the code via firebug. Basically if you create a Protocol.HTTP with a
> user callback, it never gets called. Below is a summary of my analysis
> and I would appreciate it if one of you can confirm or refute these
> observations.
>
> In OpenLayers.Protocol.HTTP.commit() near the end the code starts
> issuing requests with:
>
> var queue = types[OpenLayers.State.INSERT];
> if(queue.length > 0) {
> resp.push(this.create(
> queue, OpenLayers.Util.applyDefaults(
> {callback: insertCallback, scope: this}, options.create
> )
> ));
> }
> queue = types[OpenLayers.State.UPDATE];
> for(var i=queue.length-1; i>=0; --i) {
> resp.push(this.update(
> queue[i], OpenLayers.Util.applyDefaults(
> {callback: callback, scope: this}, options.update
> ))
> );
> }
> queue = types[OpenLayers.State.DELETE];
> for(var i=queue.length-1; i>=0; --i) {
> resp.push(this["delete"](
> queue[i], OpenLayers.Util.applyDefaults(
> {callback: callback, scope: this}, options["delete"]
> ))
> );
> }
>
> I think the arguments to OpenLayers.Util.applyDefaults(to, from) are
> reversed in the above code. I think the intent here was to create a hash
> like:
>
> options[requestType] = {callback: callback, scope: this}
>
> that would get passed as the options array to to the create, update,
> delete method respectively because this is what is expected later by the
> OpenLayers.Protocol.HTTP.callUserCallback. Also not the callback() and
> insertCallback() are local function to commit() and should not be
> confused with this.callback.
>
> And in fact the above code might be more correctly expressed as for example:
>
> queue = types[OpenLayers.State.DELETE];
> for(var i=queue.length-1; i>=0; --i) {
> var opt = OpenLayers.Util.applyDefaults(options, "delete:
> {callback: callback, scope: this});
> resp.push(this["delete"](queue[i], opt)
> );
> }
>
> It would seem, this would more accurately reflect the usage below in
> callUserCallback():
>
> callUserCallback: function(resp, options) {
> var opt = options[resp.requestType];
> if(opt && opt.callback) {
> opt.callback.call(opt.scope, resp);
> }
> },
>
> In current code (OL 2.8 and OL 2.9) opt is currently always undefined so
> the callback never gets called.
I think this is expected.
For the "commit" operation multiple callbacks come into play. The main
callback, called when the full commit operation completes, is set in
the "callback" option. Sub-operation callbacks can also be set.
If you had one or more of these sub-operation callbacks set you'd see
them being called in callUserCallback when committing (i.e. calling
protocol.commit()).
To set sub-operation callbacks you'd use something like the following
in the options:
"create": {
"callback": function() {
alert("create");
}
},
"update": {
"callback": function() {
alert("update");
}
},
"delete": {
"callback": function() {
alert("delete");
}
}
>
> A simple test of this is to create an OpenLayers.Protocol.HTTP with a
>
> callback: function() {alert( "Hello World!"); }
>
> and issue a create, update, or delete request via the protocol and the
> callback is not currently called.
The callback function should get called here. I'd be interested in a
example showing this doesn't work.
Cheers,
--
Eric Lemoine
Camptocamp France SAS
Savoie Technolac, BP 352
73377 Le Bourget du Lac, Cedex
Tel : 00 33 4 79 44 44 96
Mail : eric.lemo...@camptocamp.com
http://www.camptocamp.com
_______________________________________________
Dev mailing list
Dev@openlayers.org
http://openlayers.org/mailman/listinfo/dev
