[OpenLayers-Dev] multipleSelectFeature on one layer
Alexandre Dube
adube at mapgears.com
Mon Jan 26 13:56:49 EST 2009
Alexandre Dube wrote:
> Hi,
>
> Here's an other possibility :
>
> SFA : selectedFeature Array
> RI : renderIntent
> RIA : renderIntent Array
>
> Let's say we forget about the controls to have their own SFA. Only
> the layer has its own SFA.
>
> on featureselect
> if feature is not in SFA
> add feature to SFA
> trigger featureselected
> add RI of the control to the feature's RIA
> drawFeature(feature, RI)
>
> on featureunselect
> find RI of the control unselecting and remove it from RIA
> drawFeature(feature, LastRI)
> if LastRI == "default", meaning no more controls have this feature
> selected
> remove feature from SFS
> trigger featureunselected
>
> Issues :
> - The wierd concept here is that the events "select" are only
> triggered once.
> solution ? : They could be triggered every time the feature gets
> drawn instead of added to the array.
> - If the user define a selectStyle in the SelectFeature control,
> then the renderIntent is not added to the stack.
> solution ? : When the user define a selectStyle, it could add the
> control's renderIntent to the feature stack without using it to draw the
> feature. The only problem is that on unselection, the feature could
> sometime be drawn with the wrong color, but at least the problem of "is
> the feature still selected" would be resolved. Using renderIntent would
> be preferable that way.
>
> What do you think ?
>
forget about the below part ... ( too much copy/paste )
> On featureselect, add the feature to the SFA, add the RI of the
> control selecting it to the feature's RIA and drawFeature.
>
> On featureselect by an other control, do not add the feature in the
> SFA since it's already there but add the RI to the
>
> The SelectFeature controls does 2 things : select features ( adding
> them to the layer.sf array ) and changing the color.
>
>
forget about the above part...
>
>
> Amos Hayes wrote:
>
>> 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
>>>
>
>
>
--
Alexandre Dubé
Mapgears
www.mapgears.com
More information about the Dev
mailing list