[OpenLayers-Dev] multipleSelectFeature on one layer

Alexandre Dube adube at mapgears.com
Mon Jan 26 11:20:48 EST 2009 

Amos Hayes wrote:
>
> I think the big questions for me are:
>
> Where are you planning to store the states?

Do you mean feature.state ?  I don't understand what you mean.

>
> 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?

Since each SelectControl would have its own selectedFeatures array, you 
can easilly access them with yourControl.selectedFeatures.  By defining 
each control a different renderIntent and having a renderIntents stack 
array,  you can easilly keep track of "by what control the feature was 
selected".

I understand the fact that trying to have more than one SelectFeature at 
a time is not very logic since one control == one type of action the 
user wants to do, and normally the user wants to do 1 at a time, like :

  - select features to delete them
  - select a feature to modify its geometry then save
  - select a feature to display its attributes values in a popup

Normally, only one of theses should be active at a time, except the last 
one because it's only to display some info.  The feature doesn't get 
modified.  So, it could be active at the same time as the other two, 
with a hover:true option to display the popup when over a feature and 
changing its color.  Nothing more.  What do you think ?

Alexandre

>
> -- 
> 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
>


-- 
Alexandre Dubé
Mapgears
www.mapgears.com

More information about the Dev mailing list