[OpenLayers-Dev] How to override abstract OpenLayers.Protocol.WFS.v1?

Tim Schaub tschaub at opengeo.org
Thu Jun 30 16:19:45 EDT 2011


Adding this script after OpenLayers.js, I get the expected alerts.

     OpenLayers.Protocol.WFS.v1.prototype.foo = "bar";
     alert((new OpenLayers.Protocol.WFS.v1_0_0({})).foo);
     alert((new OpenLayers.Protocol.WFS.v1_1_0({})).foo);
     alert((new OpenLayers.Protocol.WFS({version: "1.0.0"})).foo);

Same using extend.  Can you make this simple case work?

Tim

On 6/30/11 10:46 AM, myOpenLayersUName wrote:
> Hello all,
>
> I'd like to override the handleRead function in OpenLayers.Protocol.WFS.v1
> for our application. I'd like to check what the maxFeatures value (if it was
> passed as an option) is and compare it with the number of features returned
> because, ultimately, I'd like to be able to tell the user they have reached
> this maximum and the features they are seeing in the map are not necessarily
> all the features that exist within the BBOX they specified in a GetFeature
> process.
>
> We will not alter third-party code directly and therefore I need to override
> that function from within our own application's javascript. I've done
> something similar before and it's worked fine, but for some reason I can't
> get it to work for this particular class definition and I believe it is
> because this one is an abstract class.
>
> I have created a file within our application structure that I load after the
> OpenLayers library has been loaded but before I actually use the
> functionality anywhere in our application. The file's contents are as
> follows:
>
>
> debugger;
> OpenLayers.Util.extend(OpenLayers.Protocol.WFS.v1.prototype, {
>      somevariable: null,
>
>      handleRead: function(response, options) {
>          alert("am i here?"); // TODO: check options.maxFeatures compared to
> response.features
>
>          if(options.callback) {
>              var request = response.priv;
>              if(request.status>= 200&&  request.status<  300) {
>                  // success
>                  response.features = this.parseFeatures(request);
>                  response.code = OpenLayers.Protocol.Response.SUCCESS;
>              } else {
>                  // failure
>                  response.code = OpenLayers.Protocol.Response.FAILURE;
>              }
>              options.callback.call(options.scope, response);
>          };
>      }
> });
>
>
> I know that the file is being loaded on startup because the debugger at the
> top is hit and when I step over the extend call, the
> OpenLayers.Protocol.WFS.v1.prototype has the "somevariable" added to it
> (just so I could verify the code was running). However, when the
> OpenLayers.Protocol.WFS function actually instantiates a new WFS protocol on
> which that abstract class is built, the "somevariable" is not in there and
> it certainly doesn't use my handleRead function. Again, I'm assuming (and
> please correct me if I'm wrong) that the reason this isn't working is
> because the prototypes for v1_0_0 and v1_1_0 have already been created when
> OpenLayers was loaded and my changing the abstract class on which they were
> built isn't affecting those prototypes at all.
>
> If this is the case, and really even if it isn't the case and it's some
> other problem I'm encountering, can someone suggest to me how I need to go
> about this to get the result I am looking for? After loading my above code,
> do I have to somehow reload the contents of the
> OpenLayers/Protocol/WFS/v1_0_0.js and v1_1_0.js somehow? Something else
> entirely?
>
> Can anyone point me in the right direction here?
>
> --
> View this message in context: http://osgeo-org.1803224.n2.nabble.com/How-to-override-abstract-OpenLayers-Protocol-WFS-v1-tp6534072p6534072.html
> Sent from the OpenLayers Dev mailing list archive at Nabble.com.
> _______________________________________________
> Dev mailing list
> Dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/openlayers-dev


-- 
Tim Schaub
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.


More information about the Dev mailing list