[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