Switch Control

[enjahova]

A basic toggle tool which accepts user defined "on()" and "off()" functions

Example:  http://dev.openlayers.org/sandbox/enjahova/openlayers/examples/more-controls.html

[enjahova]

Switch control + test + fix for redraw in Panel.js

[elemoine]

This control has no interaction with the map. For that reason, I don't see how it relates to OpenLayers and why it should be part of it. Sorry if I'm missing something...

[hpbrantley]

On the contrary. I believe this control allows the user interact very closely with map objects, vectors in particular. I happen to be using this control and feel it is a necessity. I currently use this control to activate a rollover/hover control to display information about buildings on my campus. I basically use it as an interface to selectFeature, however, you could have it do pretty much anything like delete features that you hover over or whateverrr.

See my page at  http://maps.cpc-fis.vanderbilt.edu/map.html. Select the light bulb control and hover over a bldg.

If this is deemed not to be apart of the controls in trunk, at least create a extentions and add it there.

[elemoine]

Replying to hpbrantley:

On the contrary. I believe this control allows the user interact very closely with map objects, vectors in particular. I happen to be using this control and feel it is a necessity. I currently use this control to activate a rollover/hover control to display information about buildings on my campus. I basically use it as an interface to selectFeature, however, you could have it do pretty much anything like delete features that you hover over or whateverrr. See my page at  http://maps.cpc-fis.vanderbilt.edu/map.html. Select the light bulb control and hover over a bldg. If this is deemed not to be apart of the controls in trunk, at least create a extentions and add it there.

The button control was recently added into trunk. Since that button control made it into trunk, I actually see no reason for not adding a control like your switch control. To be perfectly honest I don't quite see the need for adding this button control into trunk.

For consistency, I think your control should be renamed Control.Toggle.

A comment on the your code: I think the activate() and deactivate() should be changed to use the parent's methods. Something like that:

activate: function () {
    if (OpenLayers.Control.prototype.activate.call(this)) {
       this.onActivate();
    }
},

deactivate: function() {
    if (OpenLayers.Control.prototype.deactivate.call(this)) {
        this.onDeactivate();
    }
},

[tschaub]

I think this sounds like a decent idea. We could have base Toggle, Button, and Tool controls. It would then make sense for others to inherit from those (even though I chuckled at crschmidt's suggestion that anybody would inherit from Button - just to get the type property - I do see some sense in it now).

That said, I'd like to wait on adding something like this until we can have a discussion on event handling for controls and other objects. I'd be happier if we weren't stuck with another onSomething method. The issue (which I'm sure is clear) is that these methods can only be defined once. It's a pretty limited application if only one thing can be notified of an action (like a toggle being activated). In the case of a toggle being added to a control panel (or something similar) there will be at least two listeners: the panel (which should redraw) and the app designer (which will respond with whatever the toggle is supposed to do).

Giving controls an events instance would be a good first step. The one issue there is that currently the first arg returned is the browser event, which is not relevant for most application events. We can change this without breaking the api. We can also add a nice convenience method for adding listeners (a la Ext "on" for observables).

If someone wants to listen for activate/deactivate on a toggle control, they might do something like:

toggle.on({
    "activate": userActivateFunc,
    "deactivate": userDeactivateFunc,
    "scope": userObj // optional
});

Internally, this would call toggle.events.register("activate", userObj, userActivateFunc) and the same for deactivate.

Anyway, I can create a ticket and cook up a patch later. Just wanted to add my opinion that another onWhatever method in the api is not something I'd like to see.

[elemoine]

Tim, I agree with you: let's stop adding these onWhatever methods, so let's have the toggle and tool controls wait for the event-based mechanism.

[euzuro]

is this event-based mechanism in place yet? do we want to bring toggle in for 2.7? is this more of a 3.0 thing?

someone please put this ticket in the right place.

[euzuro]

This ticket clearly needs a more thorough discussion.

[crschmidt]

Not touched since 2.7, bumping.

[tschaub]

Pull back if you want this before 3.0.