[OpenLayers-Trac] [OpenLayers] #1240: navigation history control

[OpenLayers]

#1240: navigation history control
----------------------+-----------------------------------------------------
  Reporter:  tschaub  |       Owner:             
      Type:  feature  |      Status:  new        
  Priority:  minor    |   Milestone:  2.6 Release
 Component:  Control  |     Version:  2.5        
Resolution:           |    Keywords:             
     State:           |  
----------------------+-----------------------------------------------------
Comment (by tschaub):

 Ok, instead of my above suggestion of having the application designer
 construct two button controls that work with the navigation history
 control, this code has now been incorporated into the constructor for the
 control itself.  So, you now do something like:

 {{{
 var nav = new OpenLayers.Control.NavigationHistory();
 map.addControl(nav);
 nav.previous.trigger(); // one step back in history
 nav.next.trigger(); // one step forward in history
 }}}

 Those properties (previous and next) refer to full fledged button
 controls.  They get activated when the appropriate stacks are available
 and deactivated when not.

 The one missing piece is providing a way for the application designer to
 know when those dependent controls are activated/deactivated.  I've given
 the sub-controls onActivate and onDeactivate methods.  This is sub-
 optimal, but until we give controls an events instance, it follows the
 pattern elsewhere.

 Currently, controls don't do any form of notification when they become
 active/deactive.  So, if you have a control that is part of a panel and
 you call control.activate(), the panel won't know to redraw itself.  These
 sub-controls suffer from the same problem - which is really a problem at
 the panel level.

 So, I think the long-term solution is control.events.  Until then,
 onActivate and onDeactivate are the most sensible solutions.

 And, Paul, I think your comments are good ones.  For now, I like the idea
 of separating different forms of history handling.  Eventually, someone
 could tie in the browser buttons, but we'll always want to be able to keep
 them separate as well.  As mentioned above, I think this code makes a good
 generic History superclass (with the exception of on, restore, and
 initStack).  Once we get a couple implementations, we'll have a better
 idea what the API should be.

-- 
Ticket URL: <http://trac.openlayers.org/ticket/1240#comment:11>
OpenLayers <http://openlayers.org/>
A free AJAX map viewer