[OpenLayers-Dev] Layer.Vector: getFeatureBy and getFeaturesByAttribute

[Eric Lemoine]

On Mon, Dec 13, 2010 at 1:41 PM, Marc Jansen <jansen at terrestris.de> wrote:
> Hi Eric,
>
> thanks for your comments. I've added my thoughts inline:
>
>
> On 11.12.2010 22:29, Eric Lemoine wrote:
>>
>> On Thu, Dec 9, 2010 at 6:16 PM, Marc Jansen<jansen at terrestris.de>  wrote:
>>>
>>> Hi list,
>>
>> Hi Marc
>>
>>> instances of OpenLayers.Vector have a method getFeatureBy(property,
>>> value)
>>> that was introduced in revision 10691 [1] and lives in 2.10. This method
>>> returns the first feature that has the property set to the given value.
>>>
>>> Wouldn't it make more sense to have a function getFeaturesBy(property,
>>> value) that returns an array of matching features?
>>
>> I think getFeatureBy was just introduced for the purpose of
>> getFeatureById and getFeatureByFid, and id and fid are primary keys
>> here. I'm even wondering if it should be part of the API.
>
> Would you prefer hidding those methods from the API and let all application
> code work with the "features"-attribute of Vector-layers? The
> "feature"-array isn't an API-property either, is it?

I was saying that getFeatureBy could be hidden, as it's only useful to
getFeatureById and getFeatureByFid.

>
>>> AFAICT vector layers also do not provide a method to get features that
>>> have
>>> a certain attribute set to a given value. I propose a new method
>>> getFeaturesByAttribute(attrName, attrValue, strict) that would scan the
>>> attributes of features for matching candidates and eventually return
>>> those
>>> as an array (see [2] for a hardly tested implementation).
>>>
>>> What do you think?
>>
>> I would personally not add such a function to the library. My reason:
>> coding this function is easy enough, so I'd leave its implementation
>> to the application developer, thereby avoiding bloating OpenLayers
>> with code that most application developers won't need. Also, by having
>> this function in the application code, you will probably not need the
>> "strict" argument and the logic that goes with it in the core of the
>> function, so this will result in fewer bytes of JavaScript, overall.
>>
>
> I have found myself implementing different versions of the function
> myself... which is why I thought it would be better suited as reviewed
> method inside the library and not in the application code. Furthermore I
> think that the library should provide a method of getting features by their
> attributes, and that application-code has to be implemented to work on that
> result set of features. These are just my thoughts -- I can fully understand
> that others might have different thoughts on this topic.

Ok. I we introduce this function I'll suggest to remove the "strict"
logic. I think we want to be "strict" here.





-- 
Eric Lemoine

Camptocamp France SAS
Savoie Technolac, BP 352
73377 Le Bourget du Lac, Cedex

Tel : 00 33 4 79 44 44 96
Mail : eric.lemoine at camptocamp.com
http://www.camptocamp.com