I have a bunch of components with Tag bindings, and I now want to parameterize these tags and will need to make them Expression bindings instead. I know I can easily find/replace the text, but it will then be the wrong binding type. Is there any way to mass-change them all to Expression bindings, or will I have to go through one by one?
Why would parameterization require changing to expressions? (Normally, you'd change your direct tag bindings to indirect tag bindings.)
And yes, pretty much always one-by-one. Because you will also need to add parameters to your views to reference in your indirect tag bindings.
I was copying something a colleague did. They had parameters passed into the View, and a custom property in the root container to build a string for the tag folder. Then on all their bindings, they're using tag({/root.custom.tagFolder} + "tagName"). On the places where I already used an Expression binding, I was able to easily find/replace the hard-coded folder with the custom property. But I don't see a way to change my existing Direct Tag bindings to something else.
Like you're saying, I guess I could use Indirect or even Expression Tag bindings (instead of the normal Expression Binding), but still, is there any way to easily mass-swap them off of Direct bindings?
Edit: Oh, yeah. I'm not going to be able to do normal Expression bindings because I'll need some of them to be bidirectional. I can do concat() instead of tag() in an Expression Tag binding and it'll work, I'd just need an easy way to mass-swap them off of Direct binding after/when I do the folder string replace.
Do not use the tag() expression function in UI bindings. Ever.
1 Like
Technically, since Perspective config is all view.json files on disk, you could (in theory) come up with a jq snippet to run on the command line that recursively processes all your views.
Where this approach lands on the automation graph is anyone's guess:
1 Like
doing this in jq instead of python for actual dict processing is a deeply confusing take
Paul is trying to nerd-snipe you. He sometimes succeeds on me, but not with jq. 
1 Like
7 posts were merged into an existing topic: How expensive is each WebDev route
Well, considering he’s done similar things in the past perhaps he’s just trying to keep himself from being sniped.
1 Like
Horses for courses.
JSON manipulation of a deep file tree preserving everything else in the JSON structure unmodified is a more convoluted task than it seems at a glance in Python.
And LLMs are excellent at spitting out jq incantations; I've never even attempted to learn its syntax and it's served me just fine.
1 Like
I'm still convinced it doesn't have a syntax. You just mash things together and sometimes it works, sometimes you hit the randomise button again and you get lucky the 2nd time, or not 
Also
As I read each line I predicted what was to follow 
3 Likes
What's wrong with the tag() function?
In one spot, I have an Expression binding to take the inverse of a bool tag, and I have !tag("parameterized_tag_string") I tried doing concat() on the Tag Expression binding, but it didn't seem to work with the not operator. How would you recommend I do this? One solution I can see would be to make a custom property and bind it to the tag using concat(), and then bind the inverse of the custom property to the actual property, but is there a better way? I also am using the tag() function in if statements elsewhere.
Numerous performance and initialization problems. This forum is full of discussions of people's bad experiences with tag().
Move the entire tag() subexpression to an indirect tag binding on a custom property, and use that custom property in its place in the original expression.
4 Likes
There is generally no need for concat() in this context either, as this is exactly the problem that Indirect Tag Bindings were made to solve.
4 Likes
Yeah, I know it's not necessary, but it would be faster to copy/paste the concat() function I already have than to remake it as an indirect binding. But actually, I think I will take the extra time to make them indirect bindings.
I think my final approach will have to be going one-by-one since I don't know anything about jq to automate changing Direct bindings to Indirect bindings. And in places where I have expressions (nots, if statements, etc.), I can still use the Indirect Tag binding with an Expression transform. I'd like to avoid using Custom properties if I can. I'm working in an RDP, and it seems like sometimes when I'm creating Custom properties, the RDP connection freezes. I know correlation doesn't mean causation, but it still feels better to have everything contained in a single binding/property.
You should avoid transforms, too, for performance. A separate custom property for the indirect tag binding is substantially better.
Ignition provides many ways to solve data flow problems, but they are not all equally good.
4 Likes
Even if you're only using the tag value in the one spot?
(For troubleshooting and testing it's obviously better to have a separate prop with the tag binding)
Yes, it seems so. (I haven't exhaustively tested this.) It is important to mark the custom property as private for best results.
Transforms have significant overhead, and require all parts of the binding to execute every time. Having separate properties with separate bindings means only the parts that need to execute (due to reference changes) will consume CPU.
3 Likes
Is the rule to basically set all custom props to private? I assume no props/position/meta property groups can be made private? What about params?