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 > [email protected] > +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 <[email protected]>: >>>> >>>> >>>>> 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 >>>>> [email protected] >>>>> http://openlayers.org/mailman/listinfo/dev >>>>> >>>>> >>>>> >>> >>> >>> >> >> >> -- >> Alexandre Dubé >> Mapgears >> www.mapgears.com >> >> _______________________________________________ >> Dev mailing list >> [email protected] >> http://openlayers.org/mailman/listinfo/dev > -- Alexandre Dubé Mapgears www.mapgears.com _______________________________________________ Dev mailing list [email protected] http://openlayers.org/mailman/listinfo/dev
