function
layer_property takes a layer name/id and a property (eg 'crs')
and returns the matching value. This approach is more flexible than
having all these values as variables, since it allows retrieval
of properties of a layer from contexts which aren't layer-aware
(eg a composer label showing the metadata of a layer).
This commit adds the ability for expressions to be evaluated against
specific contexts. It replaces the previous behaviour where
expressions were evaluated against a specific feature and could
utilise fragile global "special columns".
Now, expressions are instead evaluated using a context designed for
each individual expression. This is done via QgsExpressionContext
and QgsExpressionContextScope objects.
A QgsExpressionContextScope encapsulates the variables and functions
relating to a specific context. For instance, scopes can be created
for "global" variables (such as QGIS version, platform, and user-set
variables specified within the QGIS options dialog. Think things
like user name, work department, etc), or for "project" variables
(eg project path, title, filename, and user-set variables set
through the project properties dialog. Project version, reference
number, that kind of thing). Many more scopes are planned, including
map layer scopes (variables for layer name, id, user-set variables
through the layer properties dialog), composer scopes, etc...
QgsExpressionContextScopes are 'stacked' into a QgsExpressionContext
object. Scopes added later to a QgsExpressionContext will override
any variables or functions provided by earlier scopes, so for
instance a user could override their global 'author' variable set
within QGIS options with a different 'author' set via the project
properties dialog.
The intended use is that a QgsExpressionContext is created before
a batch set of QgsExpression evaluations. Scopes are then added to
the context based on what makes sense for that particular
expression. Eg, almost all contexts will consist of the global
scope and project scope, and then additional scopes as required.
So a composer label would be evaluated against a context
consisting of the global scope, project scope, composition scope
and finally composer item scope. The batch set of expression
evaluations would then be performed using this context, after which
the context is discarded. In other words, a context is designed
for use for one specific set of expression evaluations only.
Ignore some obvious members which don't require docs:
- constructors with no arguments
- = and == operators
Also show list of undocumented members for each class
Previously multi-line text would overflow onto neighbouring cells.
Now rows will be expanded to fit required height of text.
Fix#10273.
Sponsored by City of Uster
Adds new data defined control for the map layers to show in a
composer map. Expression result should be a | delimited list of
layer names which will be shown in the map.
Sponsored by City of Uster
Example:
with edit(layer):
f=layer.getFeatures().next()
f[0]=5
layer.updateFeature(f)
This will automatically call commitChanges() in the end.
If any exception occurs, it will rollBack() all the changes.
