[OpenLayers-Dev] multipleSelectFeature on one layer

[Amos Hayes]

Sorry, that should have read 'the 4 states to worry about'.

Also, I can envision a case where you do multiple selection by  
dragging a box. In that case, you might go from state 1 to state 4  
without going through 2 and 3. Either way, it should be possible to  
change state from any to any and have the styles keep up.

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

On 23-Jan-09, at 3:42 PM, Amos Hayes wrote:

> Hi Alexandre.
>
> I like the idea of a stack of styles.
>
> If we use select (clicked) and hover (moused over) as distinct  
> terms, then the 4 styles to worry about are:
>
> 1. Not selected and not hovering (normal)
> 2. Not selected but hovering (user is exploring with the mouse)
> 3. Selected and hovering (user has made a selection and mouse is  
> over the selected feature)
> 4. Selected but not hovering (user has made a selection but is now  
> somewhere else with the mouse)
>
> It should be possible to style each of these feature states  
> differently. Any style stacking code would have to be able to go  
> from one to four and back again. Application developers will also  
> want a way to put the feature directly into any one of those states.
>
> Hope that helps.
>
> --
> Amos Hayes
> Geomatics and Cartographic Research Centre
> Carleton University
> ahayes at gcrc.carleton.ca
> +1.613.520.2600x8179
>
> On 23-Jan-09, at 3:10 PM, Alexandre Dube wrote:
>
>> 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
>