[OpenLayers-Dev] multipleSelectFeature on one layer

Amos Hayes ahayes at gcrc.carleton.ca
Mon Jan 26 11:08:11 EST 2009 

I think the big questions for me are:

Where are you planning to store the states?

How will an app developer obtain a list of currently selected features  
and distinguish between the 'selections' that have been applied if  
more than one control has been set up?

--
Amos Hayes
Geomatics and Cartographic Research Centre
Carleton University
ahayes at gcrc.carleton.ca
+1.613.520.2600x8179

On 26-Jan-09, at 10:13 AM, Alexandre Dube wrote:

> Hi devs,
>
>  My only problem remaining : should the layer keep its selectedFeature
> array ?  If so, on selection, it's easy to know if a feature is  
> already
> selected.  As soon as one control adds it to its own array, it  
> checks in
> the layer's one and add it if it's not there.
>
>  But for unselection, before removing it from the layer's array, we
> would need to check all select features control and all controls
> containing select features control.  Since we can easily say that one
> control does a specific task at a time, I don't really see the use of
> the selectedFeatures array in the layer.  I would just remove it and
> avoid the above problem.  What do you think ?
>
> Alexandre
>
> Alexandre Dube wrote:
>> Hi Eric,
>>
>>  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.
>>
>> Alexandre
>>
>> 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?
>>>
>>> Eric
>>>
>>> 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
>>>> case.
>>>>
>>>> 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
>>>>
>>>> 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
>>>>> selectedFeatures.
>>>>>
>>>>>  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 ?
>>>>>
>>>>>  Regards,
>>>>>
>>>>>
>>>>>
>>>>>
>>>> --
>>>> Alexandre Dubé
>>>> Mapgears
>>>> www.mapgears.com
>>>>
>>>> _______________________________________________
>>>> Dev mailing list
>>>> Dev at openlayers.org
>>>> http://openlayers.org/mailman/listinfo/dev
>>>>
>>>>
>>>>
>>
>>
>>
>
>
> -- 
> Alexandre Dubé
> Mapgears
> www.mapgears.com
>
> _______________________________________________
> Dev mailing list
> Dev at openlayers.org
> http://openlayers.org/mailman/listinfo/dev

More information about the Dev mailing list