[Qgis-developer] Ideas/proposal for Attribute Table

Martin Dobias wonder.sk at gmail.com
Tue Jan 7 18:49:48 PST 2014

On Wed, Jan 8, 2014 at 3:00 AM, Nyall Dawson <nyall.dawson at 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

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


More information about the Qgis-developer mailing list