# How can I loop through all the objects inside a container in perspective **URL:** \ **Category:** Ignition Early Access\ **Created:** [October 20, 2021, 3:40pm UTC](https://forum.inductiveautomation.com/t/how-can-i-loop-through-all-the-objects-inside-a-container-in-perspective/52166 "2021-10-20T15:40:13Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![nader.chinichian](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/nader.chinichian/32/9261_2.png) [@nader.chinichian](https://forum.inductiveautomation.com/u/nader.chinichian)\ **Post date:** [October 20, 2021, 3:40pm UTC](https://forum.inductiveautomation.com/t/how-can-i-loop-through-all-the-objects-inside-a-container-in-perspective/52166/1 "2021-10-20T15:40:13Z")
Hello, I’d like to browse(loop through) every object/component inside a container in perspective. Is this possible this possible? ---
**Author:** ![paul-griffith](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/paul-griffith/32/37249_2.png) [@paul-griffith](https://forum.inductiveautomation.com/u/paul-griffith)\ **Post date:** [October 20, 2021, 3:49pm UTC](https://forum.inductiveautomation.com/t/how-can-i-loop-through-all-the-objects-inside-a-container-in-perspective/52166/2 "2021-10-20T15:49:48Z")
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? ---
**Author:** ![bkarabinchak.psi](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/bkarabinchak.psi/32/83567_2.png) [@bkarabinchak.psi](https://forum.inductiveautomation.com/u/bkarabinchak.psi)\ **Post date:** [October 20, 2021, 4:43pm UTC](https://forum.inductiveautomation.com/t/how-can-i-loop-through-all-the-objects-inside-a-container-in-perspective/52166/3 "2021-10-20T16:43:23Z")
> [@Iterate through all components programatically in Perspective?](https://forum.inductiveautomation.com/t/iterate-through-all-components-programatically-in-perspective/32938): > > 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? ---
**Author:** ![bkarabinchak.psi](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/bkarabinchak.psi/32/83567_2.png) [@bkarabinchak.psi](https://forum.inductiveautomation.com/u/bkarabinchak.psi)\ **Post date:** [October 20, 2021, 6:34pm UTC](https://forum.inductiveautomation.com/t/how-can-i-loop-through-all-the-objects-inside-a-container-in-perspective/52166/4 "2021-10-20T18:34:21Z")
@paul-griffith 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. ---
**Author:** ![nader.chinichian](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/nader.chinichian/32/9261_2.png) [@nader.chinichian](https://forum.inductiveautomation.com/u/nader.chinichian)\ **Post date:** [October 20, 2021, 6:41pm UTC](https://forum.inductiveautomation.com/t/how-can-i-loop-through-all-the-objects-inside-a-container-in-perspective/52166/5 "2021-10-20T18:41:24Z")
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. ---
**Author:** ![paul-griffith](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/paul-griffith/32/37249_2.png) [@paul-griffith](https://forum.inductiveautomation.com/u/paul-griffith)\ **Post date:** [October 20, 2021, 7:15pm UTC](https://forum.inductiveautomation.com/t/how-can-i-loop-through-all-the-objects-inside-a-container-in-perspective/52166/6 "2021-10-20T19:15:41Z")
> [@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. ---
**Author:** ![bkarabinchak.psi](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/bkarabinchak.psi/32/83567_2.png) [@bkarabinchak.psi](https://forum.inductiveautomation.com/u/bkarabinchak.psi)\ **Post date:** [October 20, 2021, 7:25pm UTC](https://forum.inductiveautomation.com/t/how-can-i-loop-through-all-the-objects-inside-a-container-in-perspective/52166/7 "2021-10-20T19:25:43Z")
> [@paul-griffith](#): > > 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.