How can I loop through all the objects inside a container in perspective

Hello,

I’d like to browse(loop through) every object/component inside a container in perspective.
Is this possible this possible?

Each component has a getChildren() method; you could build a recursive function that starts from the root container, calls getChildren(), and so on.

What’s the end goal?

1 Like
1 Like

@PGriffith What I use this for in vision and perspective is to easily get all the data off of a window or view.

I use a prefix in my component names, say like _out_someName and then these components have a custom property called _out_. I iterate through all the components, if they have the right prefix, I grab the custom property, stuff it all into a dictionary that is then ready to go into a namedQuery immediately.

I only say what my use is because I think it would be a very nice to have to have this feature built in. Currently whenever I see other projects that I haven’t put this library on, if a form has 30 fields, then its 30 lines of code just getting the data from the window/view. Named queries have at least then stopped the 30 field string interpolations I have seen in the older versions of Ignition, but the prior part being a one liner would be really nice too.

I feel like this must be a 3rd party module already somewhere though. I personally I got tired of spending when I was making a new form window just making all the variables, one variable per field, finding the path every time, hence why I made my custom naming convention function.

Related - would the function I built be called a serializer? I don’t know exactly how to classify, but if I knew “what” it was, I could do a little research to make it even better.

I want to do some search on all existing p&Id components in a view which are dynamic s and change some property of them base on some other variables each time user open the page.
It is nice if this method be in the document.

I think Nick Mudge made a similar ‘automatic form’ tool for Vision (a long time ago). I definitely see the utility, and we’ve got an internal ticket to do something to make ‘forms’ a higher-level concept in Perspective.

The downside to automatic introspection of window properties is how fragile it could be. In a ‘real’ programming language, you might use annotations or decorators or some other metaprogramming to automatically enroll properties in form submissions; there’s no great analogue for that in either Vision or Perspective.

I don’t think serializer is quite appropriate, although it’s not far off - serialization is storing runtime state into persistent storage, and generally implies _de_serialization to do the inverse. In your case you’re doing that for the data, but not the entire window state including components, for instance.

Agreed, I’ve gotten in touch with our documentation team.

1 Like

Haha I sort of ran into this I think when I was trying out my window semi-serializer lets call it. My naming conventions of the components carried a lot of info. Before I made it simpler and always had an out custom property that was grabbed, I had a map of properties you could grab. So my component names would be like _out_someDBColumnName_validatorIfPresent_propertyToGrab, out indicating to use this component, someDBColumnName becoming the key of the dictionary, propertyToGrab being something like ‘float’ or ‘floatr2’ for a rounded float, and then a validatorIfPresent would be something like nonZero which would mean to make sure the property that was just grabbed was > 0, or throw a custom FormError.

Of course then the error message was using my internal someDBColumnName which didn’t match what the user saw on screen, requiring another mapping, and then I started to wonder if all of this was worth it lol.