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 >> aha...@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 <ad...@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@openlayers.org >>>>>> http://openlayers.org/mailman/listinfo/dev >>>>>> >>>>>> >>>>>> >>>>>> >>>> >>>> >>> -- >>> Alexandre Dubé >>> Mapgears >>> www.mapgears.com >>> >>> _______________________________________________ >>> Dev mailing list >>> Dev@openlayers.org >>> http://openlayers.org/mailman/listinfo/dev >>> > > > -- Alexandre Dubé Mapgears www.mapgears.com _______________________________________________ Dev mailing list Dev@openlayers.org http://openlayers.org/mailman/listinfo/dev