On Wed, Jan 8, 2014 at 3:00 AM, Nyall Dawson <nyall.daw...@gmail.com> wrote: >> >> Adding to QgsExpression doesn't make much sense as QgsExpression is only >> based on a single feature. You would need layer on top of if with functions >> that can do aggregates. >> >> - Nathan >> > > I would love to see layer stats in QgsExpression. Then it'd be possible to > generate expressions which could compare individual features to the entire > layer - eg testing if a value is greater than the layer mean, etc...
I could imagine aggregate functions as another layer on top of QgsExpression instead of implementing the support directly into QgsExpression. There could be a class that would deal with the whole layer and register the aggregate functions to instances of the expression engine where appropriate. This would keep the design clean. > There's already a bunch of non-feature specific functions in QgsExpression > and a lot of demand for even more. One thing I am worried about is the increasing number of custom functions which make sense just in a particular context (e.g. in composer). The issue is the fact that registering of functions and setting "special columns" is done with static functions, therefore affecting all instances of QgsExpression. Functions and special columns valid in a particular context (field calculator, rendering, ...) should be made available only for instances where it makes sense. I can imagine this as having "expression context" classes that would extend the basic set of functionality of QgsExpression with more functions. We could have contexts for: - field calculator: $rownum - rendering: $scale - composer: "rendering context" + $map - atlas: "composer context" + $page, $numpages, ... - aggregate: min(), max(), avg(), sum(), count() These contexts could be passed as a second parameter in QgsExpression constructor. Moreover, I am still not convinced that we need "special columns" in QgsExpression - they should be handled as functions with zero arguments to keep things simple. I think we should fix these issues before adding more extensions to QgsExpression, otherwise we may get into trouble in the future, especially if multi-threaded execution will get more common. For example, printing atlas pages in parallel would make things like $page or $feature vulnerable to run conditions - e.g. sometimes it could print everything correctly, other times all pages could have the same number! Regards Martin _______________________________________________ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
