GOverseer and GObserver Javascript packages

Designed to fit into the GMap2 library

I began working with the GMarkerManager class and soon came upon the all to often task of trying to "focus" the map on a collection of markers such that the view port was at a maximum zoom level and position that appropriately encompassed all markers in the collection. I figured there would have to be some functions of the map that would handle this for me, or some function within the GMarkerManager class. Unfortunately I was unable to find a direct solution to this problem. Although I did figure out by using pieces of the API I could easily create the solution and avoid performing any sorting or geo-calculations myself.

Implement the Solution

I began work on creating a javascript class similar to GMarkerManager but with some slight differences. First I'd be using prototype.js to help allow further extensions. Next I want something more aware of additions to the map so I wouldn't have to keep track of my class's instance and only be able to add the marker through the instance. So I set up some events to recognize when a GMarker is being added to the map. Also made it aware of when the map was cleared, I found no way to flush the GMarkerManager instance by any "public" methods or properties. This level of transparency really makes the class easy to use and its interactions are much more seamless, only needing the instance when you need to add markers with specific properties. Those that are transparently added by catching them in the addoverlay event are added with the default max/min zooms of the instance, which can easily be customized at run time.

The Patterns Involved

I have begun to really see benefits of proper programming practices and in particular the advantage of patterns in the program. The GOverseer classes are built in reference to a factory pattern in that they create and manage the collection of GObserver instances, so it also plays the role of the Observer's "subject" in that it will notify all observers of a change when necessary. Each sub-class of GOverlayOverseer can produce its own particular observer objects, as long the object is instantiated from a class that implements the IGOverlayObserver interface.
A great book about design patterns

A Split in Design

Markers weren't enough for me though, I had to be able to handle any Overlay, there is an interface, there must be common properties I can rely on to accomplish an adaptor class. Unfortunately a huge inhibitor was the lack of the hide, show methods in the GPolygon classes. This ruins the auto detection mechanisms I had created for the markers. As it managed only the visibility with the markers by using hide/show methods it has no event interference. The GPolygons must be removed and re-added, causing duplications when it caught the overlay it just added being added. So Unforuntaley the pleasing transparent design can not be accomplished by classes extending from the GPolyOverseerBase. But it does manage its collections very well but you must maintain the reference to its intantiation and explicitally add the polygons through the instance.

The Brass Tacks

The general idea is to have a class that accepts a GMap instance and attaches its own event listeners to assist in the management of overlays. The GOverlayOverseer accepts an instantiation of a map, attaches it's event listeners and then manages a collection of GOverlayObserver objects. The Observer object holds a reference to the overlay, and also has the responsibility of determining whether it should be shown in the current view port. The Overseer class handles the event management and updates its observer chain when necessary. So the Overseer says "Should you be shown or hidden?" and the Observer object says yes or no. The Overseer class then takes the proper action whether that be detaching the overlay or hiding the object from the map.

Future Documentation

As of right now I only have time to roughly blog about this idea but I am very confident in its design and how it will lend to further extensions and use. I hope to soon launch this as a product with more formal documentation. But for now I do have a UML diagram to help.

• Download the GOverseer package.
• A great reference for UML