[OpenLayers-Users] Control/SelectFeature.js - selectBox

corey alix coreyalix at hotmail.com
Wed Jun 6 11:40:46 PDT 2012


This is a proposal for a code change to Control/SelectFeature.js.

The selectBox method publishes both "boxselectionstart" and
"boxselectionend" but probably not in a consistent way.  

Consider how the /select/(feature) method is handled:

*  onBeforeSelect(feature)
* triggerEvent("beforefeatureselected", {feature: feature})
* processing logic
* triggerEvent("featureselected", {feature: feature})
* onSelect(feature)

Both onBeforeSelect and "beforefeatureselected" can terminate further
processing.

Now consider /selectBox(point)/:
* calculate the bounds from the position
* triggerEvent("boxselectionstart", {layers: layers})
* processing logic
* triggerEvent("boxselectionend", {layers: layers})

Missing is an onBeforeSelectBox(position), "boxselectionstart" can not
terminate further processing, no way of knowing the position and/or bounds
of the box...

I'd argue that (at a minimum of change) the intent of the following should
be added to this method:

>start of change
            var cont = this.events.triggerEvent("beforeboxselection",
{position: position, bounds: bounds}); // maybe just position to remain
consistent
            if(cont === false) return;
>end of change
            // because we're using a box, we consider we want multiple
selection
            var prevMultiple = this.multiple;
            this.multiple = true;
            var layers = this.layers || [this.layer];
            this.events.triggerEvent("boxselectionstart", {layers: layers}); 

Such a change would both facilitate pre-processing of the bounds as well as
all skipping the default behavior.

--
View this message in context: http://osgeo-org.1560.n6.nabble.com/Control-SelectFeature-js-selectBox-tp4979574.html
Sent from the OpenLayers Users mailing list archive at Nabble.com.


More information about the Users mailing list