<p dir="ltr"><br>
On 6 Apr 2016 23:23, "Matthias Kuhn" <<a href="mailto:matthias@opengis.ch">matthias@opengis.ch</a>> wrote:<br>
><br>
> Hi Victor,<br>
><br>
> On 04/06/2016 02:49 PM, Victor Olaya wrote:<br>
> > Hi all<br>
> ><br>
> > I am trying to add support for QGIS variables in Processing, since<br>
> > that can be a useful functionality. To start with, I want to add it to<br>
> > scripts, so you can use the @variable syntax in Processing scripts as<br>
> > well<br>
> ><br>
> > It is easy to implement that, but the scope here is not so clear as in<br>
> > other places in QGIS where variables are used. It would be nice to<br>
> > have the project scope, but also the layer scope of the layers that<br>
> > are used are input. I was thinking of using @variable for the project<br>
> > scope and layername@variable for the layer scope, but before<br>
> > introducing a new notation, I would like to get ideas and feedback<br>
> > from you.<br>
> ><br>
> > Of course, people writing scripts can get variables using the<br>
> > QgsExpressionContextScope class...but i want to make it easier and<br>
> > have it documented for script developers that do not want to  having<br>
> > to dive in the QGIS API docs...<br>
> ><br>
> > Please, feel free to comment and tell me what you think of this idea,<br>
> > and how you think it would be better to implement it. In a second<br>
> > step, support might be added to the algorithm dialogs, so inputs such<br>
> > as numbers or strings can be entered using variables.<br>
><br>
> That sounds like an interesting integration.<br>
><br>
> One question I have is if it's required to see variables as an isolated<br>
> topic outside of expressions. Or if whenever a variable is required, a<br>
> complete expression would offer much more flexibility.<br>
><br>
> I also think that it's often implicitly clear from the context an<br>
> expression appears in, which layer should be the source of the variables.</p>
<p dir="ltr">Matthias is right. If a user is trying to access a layer variable *outside* of a single layer's context then they are doing things wrong and should be using a project variable instead.</p>
<p dir="ltr">There really shouldn't be any need to access a layer variable outside of the layer's scope (even via a function). Effectively they are like protected variables in a c++ class. So layer dependant contexts (eg labelling, symbology) can access them, but higher contexts (map canvas, composer) can't.</p>
<p dir="ltr">I'd suggest just using the global and project scopes, and then adding the layer scope only when the expression/value is used in a single layer context.</p>
<p dir="ltr">Cool idea btw! </p>
<p dir="ltr">Maybe you could add a processing model scope that an individual model run will temporarily store its own variables in. Then a new set variable algorithm added, and also the option to store non spatial calculation results in a variables. That + ability to use variables/expressions in parameters would add a *ton* of new possibilities to models!</p>
<p dir="ltr">Nyall</p>
<p dir="ltr">><br>
> What are the use cases you have in mind?<br>
><br>
> Cheers<br>
> Matthias<br>
><br>
> --<br>
> Matthias Kuhn<br>
> OPENGIS.ch - <a href="https://www.opengis.ch">https://www.opengis.ch</a><br>
> Spatial • (Q)GIS • PostGIS • Open Source<br>
><br>
><br>
><br>
> _______________________________________________<br>
> Qgis-developer mailing list<br>
> <a href="mailto:Qgis-developer@lists.osgeo.org">Qgis-developer@lists.osgeo.org</a><br>
> List info: <a href="http://lists.osgeo.org/mailman/listinfo/qgis-developer">http://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
> Unsubscribe: <a href="http://lists.osgeo.org/mailman/listinfo/qgis-developer">http://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
</p>