[OpenLayers-Dev] multipleSelectFeature on one layer
adube at mapgears.com
Mon Jan 26 08:34:00 EST 2009
You're right. So instead of removing the last renderIntent from the
stack, we need to remove the last renderIntent of the current SelectFeature.
SFC = SelectFeature Control
RIA = renderIntents array
Let's say the mouse goes hover a feature and get selected by a 1st SFC :
RIA : ["temporary"]
Then the user click it to select it with an other SFC :
RIA : ["temporary", "select"]
Then the mouse goes out of the feature, unselecting it from the 1st SFC :
RIA : ["select"]
The feature is still drawn with the "select" renderIntent. What do
you think ? With this, you don't need to have 4 different
possibilities. The user can define an infinite number of different
renderIntents, have a styleMap defining each one of them.
Eric Lemoine wrote:
> Hi Alex
> Consider this sequence: mouse goes over feature, feature is clicked
> (for selection), and clicked again (for unselection). With your "stack
> of intents" logic, the feature isn't redrawn as a result of the second
> click; instead it should be redrawn with the hover control's render
> intent, shouldn't it?
> 2009/1/23, Alexandre Dube <adube at mapgears.com>:
>> Hi devs,
>> Eric was right :
>> A first note. The current select feature implementation should
>> accomodate this use case: two controls on the same layer, one working
>> on click and the other on hover, only one of them actually changing
>> the feature style. This is achievable by registering a
>> beforefeatureselected listener, and have this listener return false.
>> Adding beforefeatureunselected might help fully accomodate that use
>> Now if we want the two controls to do feature styling, we need the
>> stuff I mentioned previously - per-control selectedFeatures arrays and
>> events. But this is unfortunately not sufficient. Use case: two
>> controls, one working on click and the other on hover, both doing
>> feature styling but with different render intents. If we have this
>> sequence "mouse goes over feature, mouse clicks feature, mouse goes
>> out of feature", then the feature ends up being rendered with the
>> "default" render intent, while it's still selected from the click
>> control's perspective. In most cases, this isn't desirable I think.
>> At this point I don't have a solution to the above issue.
>> An idea that could resolve this issue : features could have a stack of
>> renderIntent instead of a normal string value. Instead of assigning new
>> renderIntent value, it would stack in renderIntents array. Instead of
>> reseting to "default", it would remove the last renderIntent in the
>> stack. When the stack is empty, the "default" renderIntent is applied.
>> That could work. I'll try this and come back with more details.
>> Alexandre Dube wrote:
>>> Hi devs,
>>> I would like to propose some changes about the SelectFeature control.
>>> First, I'll introduce what I want to do : I want to change the color
>>> of a feature while the mouse is over it without selecting it. I managed
>>> to do this by building a customized control similar to the SelectFeature
>>> control named HighlightFeature. I shared the code and some people
>>> showed interest in this feature. In fact, it was a good enough to be
>>> added to trunk but there was a problem : it's too similar to the
>>> SelectFeature control.
>>> My first new option was to modify the SelectFeature control to be able
>>> to select and highlight. That's what I did, but I hit a wall : I needed
>>> to add more new events "beforefeaturehighlighted", "featurehighlighted",
>>> etc. a new array of highlightedFeatures, etc... That also became a
>>> pain because it was yet an other duplication of something already
>>> existant ( similair "select" feature events, an array of selected
>>> features, etc....)
>>> SO, that brings me to this solution, the first one Eric Lemoine
>>> proposed : an array of selectedFeatures and select events for the
>>> control ( without removing the ones of the layer ). Doing that, one
>>> vector layer could have multiple select feature controls that would know
>>> which feature it has selected, they could all have a different
>>> renderIntent value ( this is already possible ) or their own style.
>>> Then, the user could interact directly with the desired control's
>>> My example : One SelectFeature that select on click, has the default
>>> render intent "select", on which I register a "featureselected" to
>>> display a form to fill. And one other SelectFeature that select on
>>> hover, has a custom render intent "temporary" to have a different color
>>> and an event registered to "featureselected" to display a quick popup of
>>> the infos of the hovered feature.
>>> Even my DeleteFeature control I created a couple of weeks ago could
>>> work by using an other SelectFeature control and using its own
>>> featureSelected array.
>>> I'll make thoses small changes, an example and propose this as an
>>> enhancement. What do you think ?
>> Alexandre Dubé
>> Dev mailing list
>> Dev at openlayers.org
More information about the Dev