Hi Juergen On Tue, Feb 12, 2013 at 10:26 AM, Jürgen E. <[email protected]> wrote: >> >> I have been thinking also about providing convenience getFeatures() >> call, for even shorter syntax: >> layer.getFeatures( fid ).nextFeature(f) > > Creating the QgsFeatureRequest implicitly in getFeatures blocks the other > options (restricting the attributes, no geometry...). > > I like the explicitness of the new interface. No more "what was this > true/false for again"? Optionally adding those to getFeatures, would > reintroduce that.
Yes, those are my concerns, too. At the same time, it would be good to simplify API where it makes sense. I am aware of the fact that such convenience functions would block using other options - but with default options being "with geometry, with all attributes" people typically should not need to use more options. Finally, I would be opposing reintroduction of "true/false" arguments for getFeatures() as those are really advanced options that "average" users should not need to used (e.g. until recently OGR always fetched geometry and all attributes). > Maybe the current interface just takes a bit of getting use to? Maybe, but IMHO we should provide simple API for simple cases to not scare potential users :-) > Having multiple constructors for QgsFeatureRequest (rect, fid, fids) however > sounds acceptable ;) Good :) >> For a direct replacement of featureAtId() calls I have thought also >> about adding getFeature() convenience call, that would return first >> feature of a request: >> f = layer.getFeature( fid ) > > Why not keep featureAtId with the old interface on top of the new api then? > And we still need to know if that feature actually exists... featureAtId() accepts those true/false arguments which I consider evil. Regarding existence of the feature, I guess checking f.isValid() is sufficient? Regards Martin _______________________________________________ Qgis-developer mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/qgis-developer
