Alan and I were talking about this.

Behaviors should be more like layers in that we should have two types of behavior objects.

1. behavior_def. A generalized type of behavior (like a layer_def is). All our current behaviors would become a behavior_def
2. A behavior itsself would be an implementation of behavior_def. These could be referenced as strings.

This solves our issue of controls very nicely as we would do 2 things.

1. Define a behavior_def called 'openlayers_behavior_map_control'. Which would take a bunch params to define which map control we wanted.
2. Implement all those controls as behaviors using openlayers_behavior_map_control, they could then be referenced as a string.

Comments

tmcw’s picture

Hey, I've gotta say that I really disagree with this... while it makes a little sense regarding controls, and may reduce the final linecount of that part of the code slightly, this would make the vast majority of controls into singletons of their classes / _defs, thus just increasing the amount of code overall and the barrier to writing behaviors. This also would complicate interaction with the behaviors and ctools frameworks pretty seriously. I feel like the benefit of this (reducing code related to controls) would be far outweighed by the addition of complexity, especially the addition of complexity for third-party behavior authors. After all, the vast majority of control-behaviors are already included in the module, and creating a new one with those as examples is very simple indeed.

tmcw’s picture

Status: Active » Fixed

This is basically decided and implemented.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.