OpenLayers Blog

All the maps that are fit to blog

Vector Behavior

April 15th, 2008 by Tim Schaub · 3 Comments

Since 2.6 is almost here, I thought it was time to look to the future again. OpenLayers currently packs a lot into its Layer classes. This is handy. It also makes it a bit hard to reuse parts of the library in areas that the original developer might not have anticipated. We’ve been improving on this with Handler and Format classes. Now it’s time to start tearing apart vector layers.

I’ve started extracting out vector layer behavior in a sandbox (that will be gone in 6 months or so). A simple example demonstrates the differences. See the old GML layer in action and compare to the new Vector2 layer with behavior. Both are pretty boring and do just about the same thing.

In the new design, instead of creating a layer like:

var layer = new OpenLayers.Layer.GML(“GML”, “gml/polygon.xml”);

The vector behavior example (v2-fixed-http-gml.html) does the following:

var layer = new OpenLayers.Layer.Vector2(“GML”, {
strategy: new OpenLayers.Strategy.Fixed(),
protocol: new OpenLayers.Protocol.HTTP({url: “gml/polygon.xml”}),
format: new OpenLayers.Format.GML()
});

Looks horrible, right? And the example name is so long and tedious as well.

The point is that the existing GML layer wraps up a bunch (well, a bit) of vector behavior into a single class. The GML layer requests all data once (that’s a strategy), it uses HTTP (that’s a protocol), and it parses responses as GML (that’s a format).

The new design separates strategy, protocol, and format. A strategy is tied to a layer (it has a reference to a layer and can only be used with a layer). A protocol is tied to a format (it has a reference to a format). You can swap out the format for a protocol (in theory) and you can use a protocol in the absence of a layer.

The result is that we can use these parts elsewhere. People can mix and match as they like. We can develop new strategies, protocols, and formats independently – assumptions about how they are integrated doesn’t need to be tied up in a layer.

Then, of course, we can make things convenient again. The GML layer can use a Fixed strategy, an HTTP protocol, and a GML format. The WFS layer can use a BBOX strategy, a WFS protocol, and a GML format. We can create strategies that automatically send updates as features are modified, we can create layers that use the AtomPub protocol, we can create layers that use a protocol to talk to client-side storage, etc.

Tags: Features · Future · Vector

3 responses so far ↓

  • 1 Ben Slater // Apr 15, 2008 at 1:14 pm

    Sounds like a step in the right direction. Anything that can make vector data work better will be time well spent.

    What other strategies are in the works besides simple?

  • 2 Chris // Apr 15, 2008 at 4:25 pm

    BBOX is one such strategy: this is the current WFS Layer strategy, where when the layer is moved, the layer re-requests features.

    More complex strategies would be (for example) an ‘editing’ strategy, which says “Get rid of features that haven’t yet been saved back to the server”, for example.

    I don’t think anything other than Simple and BBOX is in development yet: These strategies get us back to the level of functionality we have through other existing code at the moment, I believe.

  • 3 Jean-Pierre Fiset // Jun 5, 2008 at 9:06 pm

    You might think it looks horrible, but I think it is the right thing to do.

Leave a Comment