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

[nader.chinichian]

Hello,

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

[PGriffith]

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?

[bkarabinchak.psi]

Iterate through all components programatically in Perspective?

I was wondering if there's a way to iterate through all components on screen for a perspective view? I was trying to use getRootContainer and getChildren but it doesn't seem as straight forward as I thought/as it was for Vision. Any know how this is done?

[bkarabinchak.psi]

@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.

[nader.chinichian]

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.

[PGriffith]

@bkarabinchak.psi

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.

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.

@bkarabinchak.psi

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 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.

@nader.chinichian

It is nice if this method be in the document.

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

[bkarabinchak.psi]

@PGriffith

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.

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.