OpenLayers OpenLayers

Behavior for Vector Layers

The goal of this page is to develop a design for controlling the behavior of vector layers. Specifically, I'd like to be able to construct vector layers that use a specific protocol for requesting and updating remotely stored data, parse a specific data format, and employ a specific strategy for determining when to issue requests and how to manage responses - using parameterization instead of new layer subclasses.

Ideally, we'd be able to do something like: 

var layer = new OpenLayers.Layer.Vector("Well Behaved Layer", {
    protocol: someProtocol,
    format: someFormat,
    strategy: someStrategy
});

We've already got decent format classes (useful ones would be GML, Atom, and GeoJSON). Additions to the library would be OpenLayers.Protocol (and subclasses) and OpenLayers.Strategy (and subclasses).

OpenLayers.Protocol

The Protocol classes define the way to format requests for reading, creating, updating, and deleting remotely stored vector data. The logic for creating WFS requests goes in an OpenLayers.Protocol.WFS class and AtomPub goes in an OpenLayers.Protocol.AtomPub class.

The abstract OpenLayers.Protocol class exposes five API methods:

  • read - retrieve remote features
  • create - send newly created features
  • update - send modified features
  • delete - send deleted features
  • commit - create, update, and delete appropriate features depending on the state of all features on the layer

Protocol classes that probably make sense:

Questions:

  • How are things like filters established here? Are they options on the protocol? On the layer? Etc. Lack of support for WFS filters is something that has tripped up a fair number of people with our current WFS support, and if we were to support ESRI's REST stuff, I think that would be even more true.
    • It is likely that the 'read' method would always take a set of options which would then be used to modify the data request -- addig parameters, etc. Each protocol could have specific options that it supported and knew what to do with: the options would be set on the layer, and in part controlled by the layer (things like bbox being controlled by the current map extent)

OpenLayers.Strategy

The Strategy classes are used to determine when to commit modifications to local data, when to issue requests for new data, and what to do with the responses (containing new data). A very simple strategy would handle cases where new data was requested only when a layer is first drawn and would rely on the user to trigger a commit (with a save button for example). A more complex mechanism might load data as the user moved the map, and require a specific action to commit. This is how the current WFS stuff works - though the code is spread between OpenLayers.Layer.WFS, OpenLayers.Tile.WFS, and OpenLayers.Format.WFS. A more useful strategy might handle cases where commits are triggered with each feature modification, new data is requested when the viewport bounds falls outside the tile bounds, only features outside the viewport are removed from the layer, and only newly requested features not already on the layer are added.

The abstract OpenLayers.Strategy class exposes four API methods:

  • update - register listeners that determine when to request remote features
  • remove - given all features on a layer, determine which ones to remove from the layer
  • commit - register listeners that determine when to commit modifications
  • merge - given a list of features (from a response), determine which ones to add to the layer

Update: I now think the above method names were a bit contrived (in a forced effort to make a strategy look like svn). I think we can now do with activate and deactivate.