[OpenLayers-Dev] quick summary

[Christopher Schmidt]

Quickshot summary of the past couple days of OpenLayers hacking:

 * Created new branch from trunk, /sandbox/vector-2.4
 * Moved in:
   * Layer/Vector.js
   * Renderer/*
 * Changed:  
   * Feature.js -> Feature.Vector. There are now two features -- one
     designed for use with Markers, popups, etc. and one designed for
     use with geometries.
   * Parser/Writer classes now in a single 'Format', which has read()
     and write() functions which switch between strings and collections
     of features. This means that ot create a layer which is like the
     GML layer (accept a URL, put features on the map) but which 
     parses, for example, GeoRSS, requires only writing a Format() class
     for it, and then changing a single line of code.

     This also means that it is possible to take any vector layer and
     serialize it to GML with a single function call. (var g = new
     OpenLayers.Format.GML(); gml = g.write(layer.features);)
     
   * Layer.GML and Layer.WFS now use this Format class:
     http://dev.openlayers.org/sandbox/vector-2.4/examples/gml-layer.html
     http://dev.openlayers.org/sandbox/vector-2.4/examples/wfs-t.html
     (saving WFS-T doesn't work yet. I'm still working on it :)
   
 * Major changes:
   * Attributes() parsing moved into the Format() class. This makes it
     easier for other formats, but may be a performance hit. (However, I
     have run one hundred features through the GML parser and not had
     any speed problems: the speed problems are typically in rendering
     rather than raw XML parsing). This means that feature.attributes is
     now just a dict, rather than an object with an XMLNode attached.
     This means that all attribute parsing is done in one location,
     which makes it much simpler across the code.
   
   * Style.js is going away. Instead, there is an
     OpenLayers.Feature.Vector.defaultStyle (similar to
     OpenLayers.Marker.defaultMarker) which encapsulates the default
     style: various other styles will be stored where appropriate,
     usually in the controls.  
   
   * MouseListeners seemed to boil down into a concept of 'handlers': 
     there are several types of events on the map which should be encapsulated
     in handlers which have various actions. ("draw box", "draw point",
     etc.) So, there are now 'handlers' which handle the action of
     drawing a point. Controls can then turn these handlers on and off:
     this will allow trivial building of controls like the toolbar,
     because each handler has an idea of whether it is activated or
     deactivated, a toolbar only needs to encapsulate mechanisms for
     turning these functions on and off.

     http://dev.openlayers.org/sandbox/vector-2.4/examples/draw-point.html 

     Checking the box turns the point drawing control on. 
     Uncheckint it turns it off. 

     This also changes the 'box' mechanism such that you can easily tkae
     a box and do whatevery ou want with it. Handlers return the feature
     that was drawn with them, essentially: so when you draw a point
     with the DrawPoint handler, it returns the point. When you draw a
     box with the zoombox handler, it reutrns the box.

     If you look at the source of:

     http://dev.openlayers.org/sandbox/vector-2.4/examples/custom-control.html

     You can see the draw() of the control creates a 'Box' Handler
     (Handler.Box), and assigns the 'done' callback to call notice().
     This means that when the Box handler is done with drawing the box,
     it will call the notice function -- with the bounds of the box. The
     control can then do what it wants with this. In some cases, (mouse
     defaults) this might be to zoom to the bounds described by that
     box. In this case, it just 'alert()'s the pixel coordinates of the
     box.

     This solves a whole host of 'how do I change the behavior of'
     questions: it encapsulates the Handling of mouse events at a lower
     level than registering on the map, and the result is that somewhat
     hacky code (like that in MouseDefaults) moves down a level, making
     what MouseDefaults will soon be a very simple control which just
     sets up a set of handlers.


 * Testing:
   * Currently, the geometry classes have more than 150 tests. Erik has
     done an excellent review of these classes, and has pronounced them
     complete... I think :)
   * Renderer, Format and Layer tests are coming up the pipeline.
 
 * Documentation
   * The planned route for API documentation is JSDoc, and the JSDoc
     comments have been kept together for most of the code (though a few
     classes that I wrote need better docs ;))
   * There are examples demonstrating how to add simple features to
     layers, and that API is unlikely to change. Very little API change
     has happened at all betweeen the vector and vector-2.4 branch, so
     if you were using one, you should be fine with the final version
     that goes to trunk.

 * Future plans:
   The desire is to get this stuff as done as possible this week such
   that we can walk away from the Cambridge OpenLayers Hackathon with
   a working branch, and hten soon after, merge it to trunk. We are
   hoping to get everyone on board for a 2.4 release in the next 2
   weeks with vector stuff -- even if some features and functionality
   are not complete -- so long as there is a consensus that the
   existing API is solid and unlikely to change. This will let
   everyone work on continuing development of the vector code *on trunk*
   rather than on a branch.

I just want to offer a *huge* thank you to all the people who have made
this possible. The work on the vector branch is the only thing that has
made this development possible, and a *lot* of people took part in
making that happen. Camptocamp's participation especially took this code
from being a great idea to being a great tool. The vector branch is a
core example of the widespread diversity of the Open Source community
participation that has led OpenLayers to become such a great project,
and I am extremely grateful -- both as a project contributor and
*personally* -- for all the work that has been done and all the great
feedback we've gotten.

Thank you, thank you, and thank you again. It is because of development
like this that OpenLayers is going to continue to move onward and upward
into becoming the best mapping API out there.    
     
Regards,
-- 
Christopher Schmidt
MetaCarta