I only have one problem with the cooking this approach triggers. If you change 1 of the variables in the variables DAT, it causes all OPs using any of the local variables, to cook. When using a tab() approach to get the values, it suffers from the same problem, but I can put each"variable" in a separate DAT and therefore control the cooking. But using a variable is a much nicer/cleaner workflow. So I wonder if it would be possible to have it not cause a cook on all ops?
When in a nested component (“/compA/compB”), should we have a way to get/set local variables of compA from inside compB? Something like
$foo@compA >>> which would reference $foo in the node “/compA”
Would be great for situations where you have a UI component (with it’s own local vars) inside a “real” component, and want to put value changes of the UI component into the “real” components local variables. Something like
set $U_Val@$Component = $U_Val@$UI_Component * 100
This would set the local variable “U_Val” at the “real” component to the nested UIcomponent’s local variable “U_Val”.
Got one more which might be useful. How about supporting variables DATs with more columns.
Column1 would be reference as is ($foo), and the other cols by $foo[1] $foo[2] …
I think this is a real big issue. It could be perfectly used for cloned components parameters (via an immune variables DAT). But changing one parameter causing all other to cook ain’t good!
Hm this sounds interesting.
Right now the extra columns are ignored and we were reserving the third column to define a help or usage message.
We’ll need to think about this one.
Yes, exactly. This is even useful in situations where you are in a parent-grandparent hierarchy. For example:
in /a I have variable foo == something
in /a/b I want to optionally overide variable foo
So I need something like the follwoing expressions in /a/b
ifs($doOverride,$newfoo,$foo@/a)
So if the UI parameter doOverride == 1 it will use a new value ($newfoo), else it will use the parent’s value for $foo.
Again, this can be done using tab(), but it could be more elegant.
Any other idea how to overide a parent’s variable in children depending on another variable of the children?
One approach is to insert an Evaluate DAT between the nodes called set_variables and variables. You could then make an expression for the parent variable to be overridden using children’s values.
Isn’t that suggestion the same as mine from the post you quoted? Just to clarify.
In “/a/local/set_variables” I declare
foo == 11
In “/a/b/local/set_variables” I declare (in the following order, or it won’t work)
override = 1
bar = 22
foo == if($override == 1,$bar,tab("/a/local/variables",0,1))
The “problem” is that I can’t access the parent’s foo variable inside the children’s foo variable expression. So
foo == if($override == 1,$bar,$foo)
does not work, as it will return an empty string for $foo
Hence the request for $foo@/a. Alternatively, would it make sense than the eval DAT would use the parent’s foo value in the above expression? I mean, if an eval DAT evaluate a variable/row named foo and in the expression for that row/variable $foo is used, could it then look in the parent(s) for $foo (instead of looking in “itself”)?
Not a big thing as you can use tab(), but it would make it a little more elegant and readable.
Interesting, I did not realize it was doing that, now I see what you mean. I think $foo/a is better than having the eval DAT automatically use the parent’s foo value, because you might want to just look at foo locally and test for an empty value in some cases.