QGIS/python/core/qgsexpressioncontext.sip

1179 lines
33 KiB
Plaintext
Raw Normal View History

/************************************************************************
* This file has been generated automatically from *
* *
* src/core/qgsexpressioncontext.h *
* *
* Do not edit manually ! Edit header and run scripts/sipify.pl again *
************************************************************************/
New framework for context based expressions 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.
2015-08-07 15:29:51 +10:00
class QgsScopedExpressionFunction : QgsExpressionFunction
New framework for context based expressions 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.
2015-08-07 15:29:51 +10:00
{
%Docstring
Expression function for use within a QgsExpressionContextScope. This differs from a
2017-12-15 10:36:55 -04:00
standard QgsExpression.Function in that it requires an implemented
clone() method.
.. versionadded:: 2.12
%End
New framework for context based expressions 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.
2015-08-07 15:29:51 +10:00
%TypeHeaderCode
#include "qgsexpressioncontext.h"
New framework for context based expressions 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.
2015-08-07 15:29:51 +10:00
%End
public:
QgsScopedExpressionFunction( const QString &fnname,
New framework for context based expressions 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.
2015-08-07 15:29:51 +10:00
int params,
const QString &group,
const QString &helpText = QString(),
bool usesGeometry = false,
const QSet<QString> &referencedColumns = QSet<QString>(),
bool lazyEval = false,
bool handlesNull = false,
bool isContextual = true );
%Docstring
2017-12-15 10:36:55 -04:00
Create a new QgsScopedExpressionFunction
.. versionadded:: 2.12
%End
QgsScopedExpressionFunction( const QString &fnname,
const QgsExpressionFunction::ParameterList &params,
const QString &group,
const QString &helpText = QString(),
New framework for context based expressions 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.
2015-08-07 15:29:51 +10:00
bool usesGeometry = false,
const QSet<QString> &referencedColumns = QSet<QString>(),
New framework for context based expressions 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.
2015-08-07 15:29:51 +10:00
bool lazyEval = false,
bool handlesNull = false,
bool isContextual = true );
%Docstring
2017-12-15 10:36:55 -04:00
Create a new QgsScopedExpressionFunction using named parameters.
New framework for context based expressions 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.
2015-08-07 15:29:51 +10:00
.. versionadded:: 3.0
%End
New framework for context based expressions 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.
2015-08-07 15:29:51 +10:00
virtual QVariant func( const QVariantList &values, const QgsExpressionContext *context, QgsExpression *parent, const QgsExpressionNodeFunction *node ) = 0;
New framework for context based expressions 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.
2015-08-07 15:29:51 +10:00
virtual QgsScopedExpressionFunction *clone() const = 0 /Factory/;
%Docstring
2017-12-15 10:36:55 -04:00
Returns a clone of the function.
:rtype: QgsScopedExpressionFunction
%End
virtual bool usesGeometry( const QgsExpressionNodeFunction *node ) const;
virtual QSet<QString> referencedColumns( const QgsExpressionNodeFunction *node ) const;
virtual bool isStatic( const QgsExpressionNodeFunction *node, QgsExpression *parent, const QgsExpressionContext *context ) const;
New framework for context based expressions 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.
2015-08-07 15:29:51 +10:00
};
2016-02-14 03:50:23 +01:00
New framework for context based expressions 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.
2015-08-07 15:29:51 +10:00
class QgsExpressionContextScope
{
%Docstring
Single scope for storing variables and functions for use within a QgsExpressionContext.
2017-12-15 10:36:55 -04:00
Examples include a project's scope, which could contain information about the current project such as
the project file's location. QgsExpressionContextScope can encapsulate both variables (static values)
and functions(which are calculated only when an expression is evaluated).
2017-12-15 10:36:55 -04:00
See QgsExpressionContextUtils for helper methods for working with QgsExpressionContextScope objects.
.. versionadded:: 2.12
%End
New framework for context based expressions 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.
2015-08-07 15:29:51 +10:00
%TypeHeaderCode
#include "qgsexpressioncontext.h"
New framework for context based expressions 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.
2015-08-07 15:29:51 +10:00
%End
public:
struct StaticVariable
{
StaticVariable( const QString &name = QString(), const QVariant &value = QVariant(), bool readOnly = false, bool isStatic = false, const QString &description = QString() );
%Docstring
2017-12-15 10:36:55 -04:00
Constructor for StaticVariable.
:param name: variable name (should be unique within the QgsExpressionContextScope)
:param value: initial variable value
:param readOnly: true if variable should not be editable by users
:param isStatic: true if the variable will not change during the lifteime of an iterator.
:param description: optional translated description of variable, for use in expression builder widgets
%End
New framework for context based expressions 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.
2015-08-07 15:29:51 +10:00
QString name;
%Docstring
Variable name
%End
New framework for context based expressions 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.
2015-08-07 15:29:51 +10:00
QVariant value;
%Docstring
Variable value
%End
New framework for context based expressions 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.
2015-08-07 15:29:51 +10:00
bool readOnly;
%Docstring
True if variable should not be editable by users
%End
2017-05-02 00:40:24 +02:00
bool isStatic;
%Docstring
A static variable can be cached for the lifetime of a context
%End
QString description;
%Docstring
Translated description of variable, for use within expression builder widgets.
%End
New framework for context based expressions 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.
2015-08-07 15:29:51 +10:00
};
QgsExpressionContextScope( const QString &name = QString() );
%Docstring
2017-12-15 10:36:55 -04:00
Constructor for QgsExpressionContextScope
:param name: friendly display name for the context scope
%End
New framework for context based expressions 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.
2015-08-07 15:29:51 +10:00
QgsExpressionContextScope( const QgsExpressionContextScope &other );
%Docstring
2017-12-15 10:36:55 -04:00
Copy constructor
%End
New framework for context based expressions 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.
2015-08-07 15:29:51 +10:00
~QgsExpressionContextScope();
QString name() const;
%Docstring
2017-12-15 10:36:55 -04:00
Returns the friendly display name of the context scope.
:rtype: str
%End
New framework for context based expressions 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.
2015-08-07 15:29:51 +10:00
2017-05-02 00:40:24 +02:00
void setVariable( const QString &name, const QVariant &value, bool isStatic = false );
%Docstring
2017-12-15 10:36:55 -04:00
Convenience method for setting a variable in the context scope by ``name`` name and ``value``. If a variable
with the same name is already set then its value is overwritten, otherwise a new variable is added to the scope.
If the ``isStatic`` parameter is set to true, this variable can be cached during the execution
of QgsExpression.prepare().
2017-12-05 20:04:14 -04:00
.. seealso:: :py:func:`addVariable()`
%End
New framework for context based expressions 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.
2015-08-07 15:29:51 +10:00
void addVariable( const QgsExpressionContextScope::StaticVariable &variable );
%Docstring
2017-12-15 10:36:55 -04:00
Adds a variable into the context scope. If a variable with the same name is already set then its
value is overwritten, otherwise a new variable is added to the scope.
:param variable: definition of variable to insert
2017-12-05 20:04:14 -04:00
.. seealso:: :py:func:`setVariable()`
2017-12-15 10:36:55 -04:00
2017-12-05 20:04:14 -04:00
.. seealso:: :py:func:`addFunction()`
%End
New framework for context based expressions 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.
2015-08-07 15:29:51 +10:00
bool removeVariable( const QString &name );
%Docstring
2017-12-15 10:36:55 -04:00
Removes a variable from the context scope, if found.
:param name: name of variable to remove
:return: true if variable was removed from the scope, false if matching variable was not
:rtype: bool
found within the scope
%End
New framework for context based expressions 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.
2015-08-07 15:29:51 +10:00
bool hasVariable( const QString &name ) const;
%Docstring
2017-12-15 10:36:55 -04:00
Tests whether a variable with the specified name exists in the scope.
:param name: variable name
:return: true if matching variable was found in the scope
:rtype: bool
2017-12-05 20:04:14 -04:00
.. seealso:: :py:func:`variable()`
2017-12-15 10:36:55 -04:00
2017-12-05 20:04:14 -04:00
.. seealso:: :py:func:`hasFunction()`
%End
New framework for context based expressions 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.
2015-08-07 15:29:51 +10:00
QVariant variable( const QString &name ) const;
%Docstring
2017-12-15 10:36:55 -04:00
Retrieves a variable's value from the scope.
:param name: variable name
:return: variable value, or invalid QVariant if matching variable could not be found
:rtype: QVariant
2017-12-05 20:04:14 -04:00
.. seealso:: :py:func:`hasVariable()`
2017-12-15 10:36:55 -04:00
2017-12-05 20:04:14 -04:00
.. seealso:: :py:func:`function()`
%End
New framework for context based expressions 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.
2015-08-07 15:29:51 +10:00
QStringList variableNames() const;
%Docstring
2017-12-15 10:36:55 -04:00
Returns a list of variable names contained within the scope.
:rtype: list of str
2017-12-05 20:04:14 -04:00
.. seealso:: :py:func:`functionNames()`
2017-12-15 10:36:55 -04:00
2017-12-05 20:04:14 -04:00
.. seealso:: :py:func:`filteredVariableNames()`
%End
New framework for context based expressions 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.
2015-08-07 15:29:51 +10:00
2015-09-11 17:11:48 +10:00
QStringList filteredVariableNames() const;
%Docstring
2017-12-15 10:36:55 -04:00
Returns a filtered and sorted list of variable names contained within the scope.
Hidden variable names will be excluded, and the list will be sorted so that
read only variables are listed first.
:rtype: list of str
2017-12-05 20:04:14 -04:00
.. seealso:: :py:func:`variableNames()`
%End
2015-09-11 17:11:48 +10:00
bool isReadOnly( const QString &name ) const;
%Docstring
2017-12-15 10:36:55 -04:00
Tests whether the specified variable is read only and should not be editable
by users.
:param name: variable name
:return: true if variable is read only
:rtype: bool
%End
New framework for context based expressions 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.
2015-08-07 15:29:51 +10:00
2017-05-02 00:40:24 +02:00
bool isStatic( const QString &name ) const;
%Docstring
2017-12-15 10:36:55 -04:00
Tests whether the variable with the specified ``name`` is static and can
be cached.
:rtype: bool
.. versionadded:: 3.0
%End
2017-05-02 00:40:24 +02:00
QString description( const QString &name ) const;
%Docstring
2017-12-15 10:36:55 -04:00
Returns the translated description for the variable with the specified ``name``
(if set).
:rtype: str
.. versionadded:: 3.0
%End
New framework for context based expressions 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.
2015-08-07 15:29:51 +10:00
int variableCount() const;
%Docstring
2017-12-15 10:36:55 -04:00
Returns the count of variables contained within the scope.
:rtype: int
%End
New framework for context based expressions 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.
2015-08-07 15:29:51 +10:00
bool hasFunction( const QString &name ) const;
%Docstring
2017-12-15 10:36:55 -04:00
Tests whether a function with the specified name exists in the scope.
:param name: function name
:return: true if matching function was found in the scope
:rtype: bool
2017-12-05 20:04:14 -04:00
.. seealso:: :py:func:`function()`
2017-12-15 10:36:55 -04:00
2017-12-05 20:04:14 -04:00
.. seealso:: :py:func:`hasFunction()`
%End
New framework for context based expressions 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.
2015-08-07 15:29:51 +10:00
QgsExpressionFunction *function( const QString &name ) const;
%Docstring
2017-12-15 10:36:55 -04:00
Retrieves a function from the scope.
:param name: function name
:return: function, or null if matching function could not be found
:rtype: QgsExpressionFunction
2017-12-05 20:04:14 -04:00
.. seealso:: :py:func:`hasFunction()`
2017-12-15 10:36:55 -04:00
2017-12-05 20:04:14 -04:00
.. seealso:: :py:func:`functionNames()`
2017-12-15 10:36:55 -04:00
2017-12-05 20:04:14 -04:00
.. seealso:: :py:func:`variable()`
%End
New framework for context based expressions 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.
2015-08-07 15:29:51 +10:00
QStringList functionNames() const;
%Docstring
2017-12-15 10:36:55 -04:00
Retrieves a list of names of functions contained in the scope.
:rtype: list of str
2017-12-05 20:04:14 -04:00
.. seealso:: :py:func:`function()`
2017-12-15 10:36:55 -04:00
2017-12-05 20:04:14 -04:00
.. seealso:: :py:func:`variableNames()`
%End
void addFunction( const QString &name, QgsScopedExpressionFunction *function /Transfer/ );
%Docstring
2017-12-15 10:36:55 -04:00
Adds a function to the scope.
:param name: function name
:param function: function to insert. Ownership is transferred to the scope.
2017-12-05 20:04:14 -04:00
.. seealso:: :py:func:`addVariable()`
%End
New framework for context based expressions 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.
2015-08-07 15:29:51 +10:00
bool hasFeature() const;
%Docstring
2017-12-15 10:36:55 -04:00
Returns true if the scope has a feature associated with it.
:rtype: bool
.. versionadded:: 3.0
2017-12-15 10:36:55 -04:00
2017-12-05 20:04:14 -04:00
.. seealso:: :py:func:`feature()`
%End
QgsFeature feature() const;
%Docstring
2017-12-15 10:36:55 -04:00
Sets the feature associated with the scope.
:rtype: QgsFeature
2017-12-05 20:04:14 -04:00
.. seealso:: :py:func:`setFeature()`
2017-12-15 10:36:55 -04:00
2017-12-05 20:04:14 -04:00
.. seealso:: :py:func:`hasFeature()`
2017-12-15 10:36:55 -04:00
.. versionadded:: 3.0
%End
void setFeature( const QgsFeature &feature );
%Docstring
2017-12-15 10:36:55 -04:00
Convenience function for setting a feature for the scope. Any existing
feature set by the scope will be overwritten.
:param feature: feature for scope
2017-12-05 20:04:14 -04:00
.. seealso:: :py:func:`removeFeature()`
2017-12-15 10:36:55 -04:00
2017-12-05 20:04:14 -04:00
.. seealso:: :py:func:`feature()`
%End
void removeFeature();
%Docstring
2017-12-15 10:36:55 -04:00
Removes any feature associated with the scope.
.. versionadded:: 3.0
2017-12-15 10:36:55 -04:00
2017-12-05 20:04:14 -04:00
.. seealso:: :py:func:`setFeature()`
2017-12-15 10:36:55 -04:00
2017-12-05 20:04:14 -04:00
.. seealso:: :py:func:`hasFeature()`
%End
void setFields( const QgsFields &fields );
%Docstring
2017-12-15 10:36:55 -04:00
Convenience function for setting a fields for the scope. Any existing
fields set by the scope will be overwritten.
:param fields: fields for scope
%End
};
New framework for context based expressions 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.
2015-08-07 15:29:51 +10:00
class QgsExpressionContext
{
%Docstring
Expression contexts are used to encapsulate the parameters around which a QgsExpression should
2017-12-15 10:36:55 -04:00
be evaluated. QgsExpressions can then utilize the information stored within a context to contextualise
their evaluated result. A QgsExpressionContext consists of a stack of QgsExpressionContextScope objects,
where scopes added later to the stack will override conflicting variables and functions from scopes
lower in the stack.
2017-12-15 10:36:55 -04:00
See QgsExpressionContextUtils for helper methods for working with QgsExpressionContext objects.
.. versionadded:: 2.12
%End
New framework for context based expressions 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.
2015-08-07 15:29:51 +10:00
%TypeHeaderCode
#include "qgsexpressioncontext.h"
New framework for context based expressions 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.
2015-08-07 15:29:51 +10:00
%End
public:
2016-02-14 03:50:23 +01:00
QgsExpressionContext();
2017-11-11 15:22:19 +10:00
%Docstring
Constructor for QgsExpressionContext
%End
explicit QgsExpressionContext( const QList<QgsExpressionContextScope *> &scopes /Transfer/ );
%Docstring
2017-12-15 10:36:55 -04:00
Initializes the context with given list of scopes.
Ownership of the scopes is transferred to the stack.
.. versionadded:: 3.0
%End
QgsExpressionContext( const QgsExpressionContext &other );
%Docstring
2017-12-15 10:36:55 -04:00
Copy constructor
%End
New framework for context based expressions 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.
2015-08-07 15:29:51 +10:00
~QgsExpressionContext();
bool hasVariable( const QString &name ) const;
%Docstring
2017-12-15 10:36:55 -04:00
Check whether a variable is specified by any scope within the context.
:param name: variable name
:return: true if variable is set
:rtype: bool
2017-12-05 20:04:14 -04:00
.. seealso:: :py:func:`variable()`
2017-12-15 10:36:55 -04:00
2017-12-05 20:04:14 -04:00
.. seealso:: :py:func:`variableNames()`
%End
New framework for context based expressions 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.
2015-08-07 15:29:51 +10:00
QVariant variable( const QString &name ) const;
%Docstring
2017-12-15 10:36:55 -04:00
Fetches a matching variable from the context. The variable will be fetched
from the last scope contained within the context which has a matching
variable set.
:param name: variable name
:return: variable value if matching variable exists in the context, otherwise an invalid QVariant
:rtype: QVariant
2017-12-05 20:04:14 -04:00
.. seealso:: :py:func:`hasVariable()`
2017-12-15 10:36:55 -04:00
2017-12-05 20:04:14 -04:00
.. seealso:: :py:func:`variableNames()`
%End
New framework for context based expressions 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.
2015-08-07 15:29:51 +10:00
QVariantMap variablesToMap() const;
%Docstring
2017-12-15 10:36:55 -04:00
Returns a map of variable name to value representing all the expression variables
contained by the context.
:rtype: QVariantMap
.. versionadded:: 3.0
%End
bool isHighlightedVariable( const QString &name ) const;
%Docstring
2017-12-15 10:36:55 -04:00
Returns true if the specified variable name is intended to be highlighted to the
user. This is used by the expression builder to more prominently display the
variable.
:param name: variable name
:rtype: bool
2017-12-05 20:04:14 -04:00
.. seealso:: :py:func:`setHighlightedVariables()`
%End
void setHighlightedVariables( const QStringList &variableNames );
%Docstring
2017-12-15 10:36:55 -04:00
Sets the list of variable names within the context intended to be highlighted to the user. This
is used by the expression builder to more prominently display these variables.
:param variableNames: variable names to highlight
2017-12-05 20:04:14 -04:00
.. seealso:: :py:func:`isHighlightedVariable()`
%End
QgsExpressionContextScope *activeScopeForVariable( const QString &name );
%Docstring
2017-12-15 10:36:55 -04:00
Returns the currently active scope from the context for a specified variable name.
As scopes later in the stack override earlier contexts, this will be the last matching
scope which contains a matching variable.
:param name: variable name
:return: matching scope containing variable, or null if none found
:rtype: QgsExpressionContextScope
%End
New framework for context based expressions 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.
2015-08-07 15:29:51 +10:00
QgsExpressionContextScope *scope( int index );
%Docstring
2017-12-15 10:36:55 -04:00
Returns the scope at the specified index within the context.
:param index: index of scope
:return: matching scope, or null if none found
:rtype: QgsExpressionContextScope
2017-12-05 20:04:14 -04:00
.. seealso:: :py:func:`lastScope()`
%End
New framework for context based expressions 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.
2015-08-07 15:29:51 +10:00
QgsExpressionContextScope *lastScope();
%Docstring
2017-12-15 10:36:55 -04:00
Returns the last scope added to the context.
:rtype: QgsExpressionContextScope
2017-12-05 20:04:14 -04:00
.. seealso:: :py:func:`scope()`
%End
New framework for context based expressions 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.
2015-08-07 15:29:51 +10:00
QList< QgsExpressionContextScope * > scopes();
%Docstring
2017-12-15 10:36:55 -04:00
Returns a list of scopes contained within the stack.
:return: list of pointers to scopes
:rtype: list of QgsExpressionContextScope
%End
New framework for context based expressions 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.
2015-08-07 15:29:51 +10:00
int indexOfScope( QgsExpressionContextScope *scope ) const;
%Docstring
2017-12-15 10:36:55 -04:00
Returns the index of the specified scope if it exists within the context.
:param scope: scope to find
:return: index of scope, or -1 if scope was not found within the context.
:rtype: int
%End
int indexOfScope( const QString &scopeName ) const;
%Docstring
2017-12-15 10:36:55 -04:00
Returns the index of the first scope with a matching name within the context.
:param scopeName: name of scope to find
:return: index of scope, or -1 if scope was not found within the context.
:rtype: int
.. versionadded:: 3.0
%End
New framework for context based expressions 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.
2015-08-07 15:29:51 +10:00
QStringList variableNames() const;
%Docstring
2017-12-15 10:36:55 -04:00
Returns a list of variables names set by all scopes in the context.
:return: list of unique variable names
:rtype: list of str
2017-12-05 20:04:14 -04:00
.. seealso:: :py:func:`filteredVariableNames`
2017-12-15 10:36:55 -04:00
2017-12-05 20:04:14 -04:00
.. seealso:: :py:func:`functionNames`
2017-12-15 10:36:55 -04:00
2017-12-05 20:04:14 -04:00
.. seealso:: :py:func:`hasVariable`
2017-12-15 10:36:55 -04:00
2017-12-05 20:04:14 -04:00
.. seealso:: :py:func:`variable`
%End
New framework for context based expressions 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.
2015-08-07 15:29:51 +10:00
QStringList filteredVariableNames() const;
%Docstring
2017-12-15 10:36:55 -04:00
Returns a filtered list of variables names set by all scopes in the context. The included
variables are those which should be seen by users.
:return: filtered list of unique variable names
:rtype: list of str
2017-12-05 20:04:14 -04:00
.. seealso:: :py:func:`variableNames`
%End
bool isReadOnly( const QString &name ) const;
%Docstring
2017-12-15 10:36:55 -04:00
Returns whether a variable is read only, and should not be modifiable by users.
:param name: variable name
:return: true if variable is read only. Read only status will be taken from last
:rtype: bool
matching scope which contains a matching variable.
%End
New framework for context based expressions 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.
2015-08-07 15:29:51 +10:00
QString description( const QString &name ) const;
%Docstring
2017-12-15 10:36:55 -04:00
Returns a translated description string for the variable with specified ``name``.
If no specific description has been provided for the variable, the value from
QgsExpression.variableHelpText() will be returned.
2017-12-15 10:36:55 -04:00
:rtype: str
.. versionadded:: 3.0
%End
bool hasFunction( const QString &name ) const;
%Docstring
2017-12-15 10:36:55 -04:00
Checks whether a specified function is contained in the context.
:param name: function name
:return: true if context provides a matching function
:rtype: bool
2017-12-05 20:04:14 -04:00
.. seealso:: :py:func:`function`
%End
New framework for context based expressions 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.
2015-08-07 15:29:51 +10:00
QStringList functionNames() const;
%Docstring
2017-12-15 10:36:55 -04:00
Retrieves a list of function names contained in the context.
:rtype: list of str
2017-12-05 20:04:14 -04:00
.. seealso:: :py:func:`function()`
2017-12-15 10:36:55 -04:00
2017-12-05 20:04:14 -04:00
.. seealso:: :py:func:`variableNames()`
%End
QgsExpressionFunction *function( const QString &name ) const;
%Docstring
2017-12-15 10:36:55 -04:00
Fetches a matching function from the context. The function will be fetched
from the last scope contained within the context which has a matching
function set.
:param name: function name
:return: function if contained by the context, otherwise null.
:rtype: QgsExpressionFunction
2017-12-05 20:04:14 -04:00
.. seealso:: :py:func:`hasFunction`
%End
New framework for context based expressions 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.
2015-08-07 15:29:51 +10:00
int scopeCount() const;
%Docstring
2017-12-15 10:36:55 -04:00
Returns the number of scopes contained in the context.
:rtype: int
%End
New framework for context based expressions 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.
2015-08-07 15:29:51 +10:00
void appendScope( QgsExpressionContextScope *scope /Transfer/ );
%Docstring
2017-12-15 10:36:55 -04:00
Appends a scope to the end of the context. This scope will override
any matching variables or functions provided by existing scopes within the
context. Ownership of the scope is transferred to the stack.
:param scope: expression context to append to context
%End
void appendScopes( const QList<QgsExpressionContextScope *> &scopes /Transfer/ );
%Docstring
2017-12-15 10:36:55 -04:00
Appends a list of scopes to the end of the context. This scopes will override
any matching variables or functions provided by existing scopes within the
context. Ownership of the scopes is transferred to the stack.
:param scopes: scopes to append to context
.. versionadded:: 3.0
%End
New framework for context based expressions 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.
2015-08-07 15:29:51 +10:00
QgsExpressionContextScope *popScope();
%Docstring
2017-12-15 10:36:55 -04:00
Removes the last scope from the expression context and return it.
:rtype: QgsExpressionContextScope
%End
void setFeature( const QgsFeature &feature );
%Docstring
2017-12-15 10:36:55 -04:00
Convenience function for setting a feature for the context. The feature
will be set within the last scope of the context, so will override any
existing features within the context.
:param feature: feature for context
2017-12-05 20:04:14 -04:00
.. seealso:: :py:func:`feature()`
%End
New framework for context based expressions 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.
2015-08-07 15:29:51 +10:00
bool hasFeature() const;
%Docstring
2017-12-15 10:36:55 -04:00
Returns true if the context has a feature associated with it.
:rtype: bool
.. versionadded:: 3.0
2017-12-15 10:36:55 -04:00
2017-12-05 20:04:14 -04:00
.. seealso:: :py:func:`feature()`
%End
QgsFeature feature() const;
%Docstring
2017-12-15 10:36:55 -04:00
Convenience function for retrieving the feature for the context, if set.
:rtype: QgsFeature
2017-12-05 20:04:14 -04:00
.. seealso:: :py:func:`setFeature`
%End
void setFields( const QgsFields &fields );
%Docstring
2017-12-15 10:36:55 -04:00
Convenience function for setting a fields for the context. The fields
will be set within the last scope of the context, so will override any
existing fields within the context.
:param fields: fields for context
2017-12-05 20:04:14 -04:00
.. seealso:: :py:func:`fields()`
%End
QgsFields fields() const;
%Docstring
2017-12-15 10:36:55 -04:00
Convenience function for retrieving the fields for the context, if set.
:rtype: QgsFields
2017-12-05 20:04:14 -04:00
.. seealso:: :py:func:`setFields`
%End
void setOriginalValueVariable( const QVariant &value );
%Docstring
2017-12-15 10:36:55 -04:00
Sets the original value variable value for the context.
:param value: value for original value variable. This usually represents the an original widget
value before any data defined overrides have been applied.
.. versionadded:: 2.12
%End
void setCachedValue( const QString &key, const QVariant &value ) const;
%Docstring
2017-12-15 10:36:55 -04:00
Sets a value to cache within the expression context. This can be used to cache the results
of expensive expression sub-calculations, to speed up future evaluations using the same
expression context.
:param key: unique key for retrieving cached value
:param value: value to cache
2017-12-05 20:04:14 -04:00
.. seealso:: :py:func:`hasCachedValue()`
2017-12-15 10:36:55 -04:00
2017-12-05 20:04:14 -04:00
.. seealso:: :py:func:`cachedValue()`
2017-12-15 10:36:55 -04:00
2017-12-05 20:04:14 -04:00
.. seealso:: :py:func:`clearCachedValues()`
2017-12-15 10:36:55 -04:00
.. versionadded:: 2.16
%End
bool hasCachedValue( const QString &key ) const;
%Docstring
2017-12-15 10:36:55 -04:00
Returns true if the expression context contains a cached value with a matching key.
:param key: unique key used to store cached value
:rtype: bool
2017-12-05 20:04:14 -04:00
.. seealso:: :py:func:`setCachedValue()`
2017-12-15 10:36:55 -04:00
2017-12-05 20:04:14 -04:00
.. seealso:: :py:func:`cachedValue()`
2017-12-15 10:36:55 -04:00
2017-12-05 20:04:14 -04:00
.. seealso:: :py:func:`clearCachedValues()`
2017-12-15 10:36:55 -04:00
.. versionadded:: 2.16
%End
QVariant cachedValue( const QString &key ) const;
%Docstring
2017-12-15 10:36:55 -04:00
Returns the matching cached value, if set. This can be used to retrieve the previously stored results
of an expensive expression sub-calculation.
:param key: unique key used to store cached value
:return: matching cached value, or invalid QVariant if not set
:rtype: QVariant
2017-12-05 20:04:14 -04:00
.. seealso:: :py:func:`setCachedValue()`
2017-12-15 10:36:55 -04:00
2017-12-05 20:04:14 -04:00
.. seealso:: :py:func:`hasCachedValue()`
2017-12-15 10:36:55 -04:00
2017-12-05 20:04:14 -04:00
.. seealso:: :py:func:`clearCachedValues()`
2017-12-15 10:36:55 -04:00
.. versionadded:: 2.16
%End
void clearCachedValues() const;
%Docstring
2017-12-15 10:36:55 -04:00
Clears all cached values from the context.
2017-12-05 20:04:14 -04:00
.. seealso:: :py:func:`setCachedValue()`
2017-12-15 10:36:55 -04:00
2017-12-05 20:04:14 -04:00
.. seealso:: :py:func:`hasCachedValue()`
2017-12-15 10:36:55 -04:00
2017-12-05 20:04:14 -04:00
.. seealso:: :py:func:`cachedValue()`
2017-12-15 10:36:55 -04:00
.. versionadded:: 2.16
%End
static const QString EXPR_FIELDS;
%Docstring
Inbuilt variable name for fields storage
%End
static const QString EXPR_ORIGINAL_VALUE;
%Docstring
Inbuilt variable name for value original value variable
%End
static const QString EXPR_SYMBOL_COLOR;
%Docstring
Inbuilt variable name for symbol color variable
%End
static const QString EXPR_SYMBOL_ANGLE;
%Docstring
Inbuilt variable name for symbol angle variable
%End
static const QString EXPR_GEOMETRY_PART_COUNT;
%Docstring
Inbuilt variable name for geometry part count variable
%End
static const QString EXPR_GEOMETRY_PART_NUM;
%Docstring
Inbuilt variable name for geometry part number variable
%End
static const QString EXPR_GEOMETRY_POINT_COUNT;
%Docstring
Inbuilt variable name for point count variable
%End
static const QString EXPR_GEOMETRY_POINT_NUM;
%Docstring
Inbuilt variable name for point number variable
%End
2016-09-12 13:51:14 +10:00
static const QString EXPR_CLUSTER_SIZE;
%Docstring
Inbuilt variable name for cluster size variable
%End
2016-09-12 13:51:14 +10:00
static const QString EXPR_CLUSTER_COLOR;
%Docstring
Inbuilt variable name for cluster color variable
%End
New framework for context based expressions 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.
2015-08-07 15:29:51 +10:00
};
class QgsExpressionContextUtils
{
%Docstring
Contains utilities for working with QgsExpressionContext objects, including methods
2017-12-15 10:36:55 -04:00
for creating scopes for specific uses (e.g., project scopes, layer scopes).
.. versionadded:: 2.12
%End
New framework for context based expressions 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.
2015-08-07 15:29:51 +10:00
%TypeHeaderCode
#include "qgsexpressioncontext.h"
New framework for context based expressions 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.
2015-08-07 15:29:51 +10:00
%End
public:
static QgsExpressionContextScope *globalScope() /Factory/;
%Docstring
2017-12-15 10:36:55 -04:00
Creates a new scope which contains variables and functions relating to the global QGIS context.
For instance, QGIS version numbers and variables specified through QGIS options.
:rtype: QgsExpressionContextScope
2017-12-05 20:04:14 -04:00
.. seealso:: :py:func:`setGlobalVariable()`
%End
static void setGlobalVariable( const QString &name, const QVariant &value );
%Docstring
2017-12-15 10:36:55 -04:00
Sets a global context variable. This variable will be contained within scopes retrieved via
globalScope().
:param name: variable name
:param value: variable value
2017-12-05 20:04:14 -04:00
.. seealso:: :py:func:`setGlobalVariable()`
2017-12-15 10:36:55 -04:00
2017-12-05 20:04:14 -04:00
.. seealso:: :py:func:`globalScope()`
2017-12-15 10:36:55 -04:00
2017-12-05 20:04:14 -04:00
.. seealso:: :py:func:`removeGlobalVariable()`
%End
static void setGlobalVariables( const QVariantMap &variables );
%Docstring
2017-12-15 10:36:55 -04:00
Sets all global context variables. Existing global variables will be removed and replaced
with the variables specified.
:param variables: new set of global variables
2017-12-05 20:04:14 -04:00
.. seealso:: :py:func:`setGlobalVariable()`
2017-12-15 10:36:55 -04:00
2017-12-05 20:04:14 -04:00
.. seealso:: :py:func:`globalScope()`
2017-12-15 10:36:55 -04:00
2017-12-05 20:04:14 -04:00
.. seealso:: :py:func:`removeGlobalVariable()`
%End
static void removeGlobalVariable( const QString &name );
%Docstring
2017-12-15 10:36:55 -04:00
Remove a global context variable.
:param name: variable name
2017-12-05 20:04:14 -04:00
.. seealso:: :py:func:`setGlobalVariable()`
2017-12-15 10:36:55 -04:00
2017-12-05 20:04:14 -04:00
.. seealso:: :py:func:`setGlobalVariables()`
2017-12-15 10:36:55 -04:00
2017-12-05 20:04:14 -04:00
.. seealso:: :py:func:`globalScope()`
%End
static QgsExpressionContextScope *projectScope( const QgsProject *project ) /Factory/;
%Docstring
2017-12-15 10:36:55 -04:00
Creates a new scope which contains variables and functions relating to a QGIS project.
For instance, project path and title, and variables specified through the project properties.
:param project: What project to use
:rtype: QgsExpressionContextScope
2017-12-05 20:04:14 -04:00
.. seealso:: :py:func:`setProjectVariable()`
%End
static void setProjectVariable( QgsProject *project, const QString &name, const QVariant &value );
%Docstring
2017-12-15 10:36:55 -04:00
Sets a project context variable. This variable will be contained within scopes retrieved via
projectScope().
:param project: Project to apply changes to
:param name: variable name
:param value: variable value
2017-12-05 20:04:14 -04:00
.. seealso:: :py:func:`setProjectVariables()`
2017-12-15 10:36:55 -04:00
2017-12-05 20:04:14 -04:00
.. seealso:: :py:func:`removeProjectVariable()`
2017-12-15 10:36:55 -04:00
2017-12-05 20:04:14 -04:00
.. seealso:: :py:func:`projectScope()`
%End
static void setProjectVariables( QgsProject *project, const QVariantMap &variables );
%Docstring
2017-12-15 10:36:55 -04:00
Sets all project context variables. Existing project variables will be removed and replaced
with the variables specified.
:param project: Project to apply changes to
:param variables: new set of project variables
2017-12-05 20:04:14 -04:00
.. seealso:: :py:func:`setProjectVariable()`
2017-12-15 10:36:55 -04:00
2017-12-05 20:04:14 -04:00
.. seealso:: :py:func:`removeProjectVariable()`
2017-12-15 10:36:55 -04:00
2017-12-05 20:04:14 -04:00
.. seealso:: :py:func:`projectScope()`
%End
static void removeProjectVariable( QgsProject *project, const QString &name );
%Docstring
2017-12-15 10:36:55 -04:00
Remove project context variable.
:param project: Project to apply changes to
:param name: variable name
2017-12-05 20:04:14 -04:00
.. seealso:: :py:func:`setProjectVariable()`
2017-12-15 10:36:55 -04:00
2017-12-05 20:04:14 -04:00
.. seealso:: :py:func:`setProjectVariables()`
2017-12-15 10:36:55 -04:00
2017-12-05 20:04:14 -04:00
.. seealso:: :py:func:`projectScope()`
%End
New framework for context based expressions 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.
2015-08-07 15:29:51 +10:00
static QgsExpressionContextScope *layerScope( const QgsMapLayer *layer ) /Factory/;
%Docstring
2017-12-15 10:36:55 -04:00
Creates a new scope which contains variables and functions relating to a QgsMapLayer.
For instance, layer name, id and fields.
:rtype: QgsExpressionContextScope
%End
static QList<QgsExpressionContextScope *> globalProjectLayerScopes( const QgsMapLayer *layer ) /Factory/;
%Docstring
2017-12-15 10:36:55 -04:00
Creates a list of three scopes: global, layer's project and layer.
:rtype: list of QgsExpressionContextScope
.. versionadded:: 3.0
%End
New framework for context based expressions 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.
2015-08-07 15:29:51 +10:00
static void setLayerVariable( QgsMapLayer *layer, const QString &name, const QVariant &value );
%Docstring
2017-12-15 10:36:55 -04:00
Sets a layer context variable. This variable will be contained within scopes retrieved via
layerScope().
:param layer: map layer
:param name: variable name
:param value: variable value
2017-12-05 20:04:14 -04:00
.. seealso:: :py:func:`setLayerVariables()`
2017-12-15 10:36:55 -04:00
2017-12-05 20:04:14 -04:00
.. seealso:: :py:func:`layerScope()`
%End
static void setLayerVariables( QgsMapLayer *layer, const QVariantMap &variables );
%Docstring
2017-12-15 10:36:55 -04:00
Sets all layer context variables. Existing layer variables will be removed and replaced
with the variables specified.
:param layer: map layer
:param variables: new set of layer variables
2017-12-05 20:04:14 -04:00
.. seealso:: :py:func:`setLayerVariable()`
2017-12-15 10:36:55 -04:00
2017-12-05 20:04:14 -04:00
.. seealso:: :py:func:`layerScope()`
%End
static QgsExpressionContextScope *mapSettingsScope( const QgsMapSettings &mapSettings ) /Factory/;
%Docstring
2017-12-15 10:36:55 -04:00
Creates a new scope which contains variables and functions relating to a QgsMapSettings object.
For instance, map scale and rotation.
:rtype: QgsExpressionContextScope
%End
static QgsExpressionContextScope *mapToolCaptureScope( const QList<QgsPointLocator::Match> &matches ) /Factory/;
%Docstring
2017-12-15 10:36:55 -04:00
Sets the expression context variables which are available for expressions triggered by
a map tool capture like add feature.
:rtype: QgsExpressionContextScope
.. versionadded:: 3.0
%End
static QgsExpressionContextScope *updateSymbolScope( const QgsSymbol *symbol, QgsExpressionContextScope *symbolScope = 0 );
%Docstring
2017-12-15 10:36:55 -04:00
Updates a symbol scope related to a QgsSymbol to an expression context.
:param symbol: symbol to extract properties from
:param symbolScope: pointer to an existing scope to update
:rtype: QgsExpressionContextScope
.. versionadded:: 2.14
%End
static QgsExpressionContextScope *compositionScope( const QgsComposition *composition ) /Factory/;
%Docstring
2017-12-15 10:36:55 -04:00
Creates a new scope which contains variables and functions relating to a QgsComposition.
For instance, number of pages and page sizes.
:param composition: source composition
:rtype: QgsExpressionContextScope
%End
static void setCompositionVariable( QgsComposition *composition, const QString &name, const QVariant &value );
%Docstring
2017-12-15 10:36:55 -04:00
Sets a composition context variable. This variable will be contained within scopes retrieved via
compositionScope().
:param composition: target composition
:param name: variable name
:param value: variable value
2017-12-05 20:04:14 -04:00
.. seealso:: :py:func:`setCompositionVariables()`
2017-12-15 10:36:55 -04:00
2017-12-05 20:04:14 -04:00
.. seealso:: :py:func:`compositionScope()`
%End
static void setCompositionVariables( QgsComposition *composition, const QVariantMap &variables );
%Docstring
2017-12-15 10:36:55 -04:00
Sets all composition context variables. Existing composition variables will be removed and replaced
with the variables specified.
:param composition: target composition
:param variables: new set of layer variables
2017-12-05 20:04:14 -04:00
.. seealso:: :py:func:`setCompositionVariable()`
2017-12-15 10:36:55 -04:00
2017-12-05 20:04:14 -04:00
.. seealso:: :py:func:`compositionScope()`
%End
static QgsExpressionContextScope *layoutScope( const QgsLayout *layout ) /Factory/;
%Docstring
2017-12-15 10:36:55 -04:00
Creates a new scope which contains variables and functions relating to a QgsLayout ``layout``.
For instance, number of pages and page sizes.
:rtype: QgsExpressionContextScope
.. versionadded:: 3.0
%End
static void setLayoutVariable( QgsLayout *layout, const QString &name, const QVariant &value );
%Docstring
2017-12-15 10:36:55 -04:00
Sets a layout context variable. This variable will be contained within scopes retrieved via
layoutScope().
:param layout: target layout
:param name: variable name
:param value: variable value
2017-12-05 20:04:14 -04:00
.. seealso:: :py:func:`setLayoutVariables()`
2017-12-15 10:36:55 -04:00
2017-12-05 20:04:14 -04:00
.. seealso:: :py:func:`layoutScope()`
2017-12-15 10:36:55 -04:00
.. versionadded:: 3.0
%End
static void setLayoutVariables( QgsLayout *layout, const QVariantMap &variables );
%Docstring
2017-12-15 10:36:55 -04:00
Sets all layout context variables. Existing layout variables will be removed and replaced
with the variables specified.
:param layout: target layout
:param variables: new set of layer variables
2017-12-05 20:04:14 -04:00
.. seealso:: :py:func:`setLayoutVariable()`
2017-12-15 10:36:55 -04:00
2017-12-05 20:04:14 -04:00
.. seealso:: :py:func:`layoutScope()`
2017-12-15 10:36:55 -04:00
.. versionadded:: 3.0
%End
static QgsExpressionContextScope *atlasScope( const QgsAtlasComposition *atlas ) /Factory/;
%Docstring
2017-12-15 10:36:55 -04:00
Creates a new scope which contains variables and functions relating to a QgsAtlasComposition.
For instance, current page name and number.
:param atlas: source atlas. If null, a set of default atlas variables will be added to the scope.
:rtype: QgsExpressionContextScope
%End
static QgsExpressionContextScope *composerItemScope( const QgsComposerItem *composerItem ) /Factory/;
%Docstring
2017-12-15 10:36:55 -04:00
Creates a new scope which contains variables and functions relating to a QgsComposerItem.
For instance, item size and position.
:param composerItem: source composer item
:rtype: QgsExpressionContextScope
%End
static void setComposerItemVariable( QgsComposerItem *composerItem, const QString &name, const QVariant &value );
%Docstring
2017-12-15 10:36:55 -04:00
Sets a composer item context variable. This variable will be contained within scopes retrieved via
composerItemScope().
:param composerItem: target composer item
:param name: variable name
:param value: variable value
2017-12-05 20:04:14 -04:00
.. seealso:: :py:func:`setComposerItemVariables()`
2017-12-15 10:36:55 -04:00
2017-12-05 20:04:14 -04:00
.. seealso:: :py:func:`composerItemScope()`
%End
static void setComposerItemVariables( QgsComposerItem *composerItem, const QVariantMap &variables );
%Docstring
2017-12-15 10:36:55 -04:00
Sets all composition context variables. Existing compositoin variables will be removed and replaced
with the variables specified.
:param composerItem: target composer item
:param variables: new set of layer variables
2017-12-05 20:04:14 -04:00
.. seealso:: :py:func:`setComposerItemVariable()`
2017-12-15 10:36:55 -04:00
2017-12-05 20:04:14 -04:00
.. seealso:: :py:func:`composerItemScope()`
%End
static QgsExpressionContext createFeatureBasedContext( const QgsFeature &feature, const QgsFields &fields );
%Docstring
2017-12-15 10:36:55 -04:00
Helper function for creating an expression context which contains just a feature and fields
collection. Generally this method should not be used as the created context does not include
standard scopes such as the global and project scopes.
:rtype: QgsExpressionContext
%End
2016-02-14 03:50:23 +01:00
static QgsExpressionContextScope *processingAlgorithmScope( const QgsProcessingAlgorithm *algorithm, const QVariantMap &parameters, QgsProcessingContext &context ) /Factory/;
%Docstring
2017-12-15 10:36:55 -04:00
Creates a new scope which contains variables and functions relating to a processing ``algorithm``,
when used with the specified ``parameters`` and ``context``.
For instance, algorithm name and parameter functions.
:rtype: QgsExpressionContextScope
%End
[FEATURE] layer refresh and trigger actions on provider notification [needs-docs] In vector layer properties (only usefull for postgres datasources) **in the rendering tab** A "Refresh layer on notification" checkbox has been added to refresh layer on provider notification. For a postgres datasource, if a `NOTIFY qgis;` command is issued by one of the database clients, a refresh of the layer will occur. If the "Only if message is" checkbox is checked, the notification will trigger the refresh only if the message contend is the one specified, e.g. if the user enters "refresh" in the box right next to the "Only if message is" checkbox, then a `NOTIFY qgis, 'refresh';` command in the datatabase will trigger a layer refresh, but `NOTIFY qgis;` or `NOTIFY qgis, 'something else';` won't. **in the actions tab** A column "On notification" has been added, the action editor widget a has text field "Execute if notification message matches" to specify a filter for notification from the provider. The filter is a Perl-type regex. Note that, as opposed to the "layer refresh" that Exemple: - QGIS side "Execute if notification message matches" `^trigger my action` - Postgres side: `NOTIFY qgis, 'trigger my action'` will trigger the action - Postgres side: `NOTIFY qgis, 'trigger my action some additional data'` will trigger the action - Postgres side: `NOTIFY qgis, 'do not trigger my action some additional data'` will NOT trigger the action Please note that if the `^`, which means "starts with", in `^trigger my action` had been ommited, the last notification would have triggered the action because the notification message contains the `trigger my action` A new qgis variable `notification_message` is available for use in actions, it holds the contend of the notification message. To continue with the previous exemple, if the action is of python type with the code: ```python print('[% @notification_message %]') ``` The three notifictions above will result in two printed lines ``` trigger my action trigger my action some additional data ``` User Warning: For postgres providers, if the "Refresh layer on notification" is checked, or if one layer action has "On notification" specified, a new connection to the database is made to listen to postgres notifications. This olds even if transaction groups are enabled at the project level. Note that once the notification mechanism is started in a QGIS session, it will not stop, even if there is no more need for it (Refresh layer on notification" unchecked and no "On notification" in any action). Consequently the connection listening to notification will remain open. IMPLEMENTATION DETAILS: A notify signal has been added to the abstract QgsVectorDataProvider along with a setListening function that enables/disble the notification mechanism. For the moment only the postgres provider implements the notification. QgsAction has a notificationMessage member function that holds the regex to match to trigger action QgsActionManager becomes a QObject and is doing the filtering and execute actions on notifications. The notification notion extends beyond SRGBD servers (postgres and oracle at least have the notify) and the "watch file" in the delimitedtext provider could also benefit from this interface. For the postgres provider a thread is created with a second connection to the database. This thread is responsible for listening postgres notifications. It would be nice to avoid the creation of one listening chanel per provider in the case transaction groups are enabled. Please note that when listening starts (a thread and connection is created in the postgres provider) it cannot be stopped by removing the connected actions or unchecking the refresh check box. Indeed, since we don't know who needs the signals, we dont't want to stop the service. The service will not restart in the next qgis session though. If this behavior is not deemed appropriate, we could use ``` int QObject::receivers ( const char * signal ) const ``` and have QgsDataProvider::setListening return a bool to tell the caller if the signal has actually been closed.
2017-09-08 16:42:30 +02:00
static QgsExpressionContextScope *notificationScope( const QString &message = QString() ) /Factory/;
%Docstring
2017-12-15 10:36:55 -04:00
Creates a new scope which contains variables and functions relating to provider notifications
:param message: the notification message
:rtype: QgsExpressionContextScope
[FEATURE] layer refresh and trigger actions on provider notification [needs-docs] In vector layer properties (only usefull for postgres datasources) **in the rendering tab** A "Refresh layer on notification" checkbox has been added to refresh layer on provider notification. For a postgres datasource, if a `NOTIFY qgis;` command is issued by one of the database clients, a refresh of the layer will occur. If the "Only if message is" checkbox is checked, the notification will trigger the refresh only if the message contend is the one specified, e.g. if the user enters "refresh" in the box right next to the "Only if message is" checkbox, then a `NOTIFY qgis, 'refresh';` command in the datatabase will trigger a layer refresh, but `NOTIFY qgis;` or `NOTIFY qgis, 'something else';` won't. **in the actions tab** A column "On notification" has been added, the action editor widget a has text field "Execute if notification message matches" to specify a filter for notification from the provider. The filter is a Perl-type regex. Note that, as opposed to the "layer refresh" that Exemple: - QGIS side "Execute if notification message matches" `^trigger my action` - Postgres side: `NOTIFY qgis, 'trigger my action'` will trigger the action - Postgres side: `NOTIFY qgis, 'trigger my action some additional data'` will trigger the action - Postgres side: `NOTIFY qgis, 'do not trigger my action some additional data'` will NOT trigger the action Please note that if the `^`, which means "starts with", in `^trigger my action` had been ommited, the last notification would have triggered the action because the notification message contains the `trigger my action` A new qgis variable `notification_message` is available for use in actions, it holds the contend of the notification message. To continue with the previous exemple, if the action is of python type with the code: ```python print('[% @notification_message %]') ``` The three notifictions above will result in two printed lines ``` trigger my action trigger my action some additional data ``` User Warning: For postgres providers, if the "Refresh layer on notification" is checked, or if one layer action has "On notification" specified, a new connection to the database is made to listen to postgres notifications. This olds even if transaction groups are enabled at the project level. Note that once the notification mechanism is started in a QGIS session, it will not stop, even if there is no more need for it (Refresh layer on notification" unchecked and no "On notification" in any action). Consequently the connection listening to notification will remain open. IMPLEMENTATION DETAILS: A notify signal has been added to the abstract QgsVectorDataProvider along with a setListening function that enables/disble the notification mechanism. For the moment only the postgres provider implements the notification. QgsAction has a notificationMessage member function that holds the regex to match to trigger action QgsActionManager becomes a QObject and is doing the filtering and execute actions on notifications. The notification notion extends beyond SRGBD servers (postgres and oracle at least have the notify) and the "watch file" in the delimitedtext provider could also benefit from this interface. For the postgres provider a thread is created with a second connection to the database. This thread is responsible for listening postgres notifications. It would be nice to avoid the creation of one listening chanel per provider in the case transaction groups are enabled. Please note that when listening starts (a thread and connection is created in the postgres provider) it cannot be stopped by removing the connected actions or unchecking the refresh check box. Indeed, since we don't know who needs the signals, we dont't want to stop the service. The service will not restart in the next qgis session though. If this behavior is not deemed appropriate, we could use ``` int QObject::receivers ( const char * signal ) const ``` and have QgsDataProvider::setListening return a bool to tell the caller if the signal has actually been closed.
2017-09-08 16:42:30 +02:00
%End
New framework for context based expressions 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.
2015-08-07 15:29:51 +10:00
static void registerContextFunctions();
%Docstring
2017-12-15 10:36:55 -04:00
Registers all known core functions provided by QgsExpressionContextScope objects.
%End
2016-02-14 03:50:23 +01:00
New framework for context based expressions 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.
2015-08-07 15:29:51 +10:00
};
/************************************************************************
* This file has been generated automatically from *
* *
* src/core/qgsexpressioncontext.h *
* *
* Do not edit manually ! Edit header and run scripts/sipify.pl again *
************************************************************************/