[OpenLayers-Dev] multipleSelectFeature on one layer

Julien-Samuel Lacroix jlacroix at mapgears.com
Fri Jan 23 17:04:02 EST 2009


Hi,

I would also add that this idea has the benefit to support multiple 
SelectFeature at the same time, not just those 4 states. Multiple 
SelectFeature Control could play together.

Julien

Amos Hayes wrote:
> 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
> 
> _______________________________________________
> Dev mailing list
> Dev at openlayers.org
> http://openlayers.org/mailman/listinfo/dev
> 

-- 
Julien-Samuel Lacroix
Mapgears
http://www.mapgears.com/



More information about the Dev mailing list