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 [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 _______________________________________________ Dev mailing list [email protected] http://openlayers.org/mailman/listinfo/dev
