# Perspective relative references to parent component properties **URL:** \ **Category:** Ignition\ **Tags:** perspective\ **Created:** [May 10, 2022, 7:25am UTC](https://forum.inductiveautomation.com/t/perspective-relative-references-to-parent-component-properties/59388 "2022-05-10T07:25:22Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![nminchin](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/nminchin/32/6911_2.png) [@nminchin](https://forum.inductiveautomation.com/u/nminchin)\ **Post date:** [May 10, 2022, 7:25am UTC](https://forum.inductiveautomation.com/t/perspective-relative-references-to-parent-component-properties/59388/1 "2022-05-10T07:25:22Z")
It would seem as though I’m a bit confused how relative referencing works in Perspective. For example: Given this component structure ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/9/8/984967f81c851c293c151b433505eb40fe1fde6b.png) Below are the expressions to access each level of component’s `meta.name` property, from the `view.root.root_0.CoordinateContainer.foi` level: ```auto {/root.meta.name} // view.root.meta.name {..../root_0.meta.name} // view.root.root_0.meta.name {parent.meta.name} // view.root.root_0.CoordinateContainer.meta.name {this.meta.name} // view.root.root_0.CoordinateContainer.foi.meta.name ``` It looks like `{../../../root.meta.name}` syntax works as well Why is every level so different? Why can’t I use `{parent.parent.parent.meta.name}` to get to the `view.root`? Why can’t I use `{....../root.meta.name}` to get to `view.root`? I just want to be able to consistently know how to relatively traverse the components in the expression language _without having to name a component_ e.g. `parent.parent.parent.meta.name` is what I would like to use. ---
**Author:** ![nminchin](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/nminchin/32/6911_2.png) [@nminchin](https://forum.inductiveautomation.com/u/nminchin)\ **Post date:** [May 12, 2022, 5:45am UTC](https://forum.inductiveautomation.com/t/perspective-relative-references-to-parent-component-properties/59388/2 "2022-05-12T05:45:19Z")
Bump ---
**Author:** ![nminchin](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/nminchin/32/6911_2.png) [@nminchin](https://forum.inductiveautomation.com/u/nminchin)\ **Post date:** [May 16, 2022, 7:33am UTC](https://forum.inductiveautomation.com/t/perspective-relative-references-to-parent-component-properties/59388/3 "2022-05-16T07:33:35Z")
☹ does anyone know about this? ---
**Author:** ![lrose](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/lrose/32/62724_2.png) [@lrose](https://forum.inductiveautomation.com/u/lrose)\ **Post date:** [May 16, 2022, 11:29am UTC](https://forum.inductiveautomation.com/t/perspective-relative-references-to-parent-component-properties/59388/4 "2022-05-16T11:29:11Z")
Honestly, I’m as confused as you are. ---
**Author:** ![victordcq](https://avatars.discourse-cdn.com/v4/letter/v/f6c823/32.png) [@victordcq](https://forum.inductiveautomation.com/u/victordcq)\ **Post date:** [May 16, 2022, 11:31am UTC](https://forum.inductiveautomation.com/t/perspective-relative-references-to-parent-component-properties/59388/5 "2022-05-16T11:31:31Z")
I believe i once saw a topic about this wierd interaction, but i dont seem to find it again immediatly. And i dont recall what was said there xd edit: found it: > [@Perspective - Flex container - Hierarchic meta.name](https://forum.inductiveautomation.com/t/perspective-flex-container-hierarchic-meta-name/57208/7): > > [https://docs.inductiveautomation.com/display/DOC81/property](https://docs.inductiveautomation.com/display/DOC81/property) You can in Perspective, actually slight_smile I would have expected {parent.parent.parent.etc} to work, honestly. EDIT: It looks like an intentional restriction that I don’t see a way around. I’m not sure what technical limitations are implied; someone else may have more luck playing around with things: [https://files.inductiveautomation.com/sdk/javadoc/ignition81/8.1.15/com/inductiveautomation/perspective/common/api/PropertyRef.h…](https://files.inductiveautomation.com/sdk/javadoc/ignition81/8.1.15/com/inductiveautomation/perspective/common/api/PropertyRef.html) have you tried this? [https://docs.inductiveautomation.com/display/DOC81/property](https://docs.inductiveautomation.com/display/DOC81/property) (no idea if it helps tho) ---
**Author:** ![nminchin](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/nminchin/32/6911_2.png) [@nminchin](https://forum.inductiveautomation.com/u/nminchin)\ **Post date:** [May 16, 2022, 12:16pm UTC](https://forum.inductiveautomation.com/t/perspective-relative-references-to-parent-component-properties/59388/6 "2022-05-16T12:16:23Z")
Thanks (that topic title is a bit cryptic - probably why I didn’t find it 🤔) I haven’t tried using `property` but I presume it’ll have the same limitations, i’ll still give it a go though. I can’t use - or rather I don’t want to use script bindings as I’m trying to increase performance not reduce it - in this instance as it will be used in a lot of places. What I wanted to attempt to do, as a test for curiosity more than anything, was to write a script to “flatten” a view and save it as a new view. When I say “flatten” I mean replace all embedded views with their basic components to see if this increases the load speed of some of our views. To do this however, I need to remap all bindings on embedded views that use the view.custom / view.params properties. I was hoping that I could simply use {parent.parent…etc} to do that, but it seems not ☹ so I’m going to have to use some weird case logic to do it instead and use a completely different expression for each level I want to go down, which is far from ideal ---
**Author:** ![pascal.fragnoud](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pascal.fragnoud/32/24728_2.png) [@pascal.fragnoud](https://forum.inductiveautomation.com/u/pascal.fragnoud)\ **Post date:** [May 16, 2022, 12:34pm UTC](https://forum.inductiveautomation.com/t/perspective-relative-references-to-parent-component-properties/59388/7 "2022-05-16T12:34:08Z")
I seem to remember a post by someone from IA mentioning they were thinking about ‘flattening’ views on the server side. I wonder if that’s something we’ll see… ---
**Author:** ![nminchin](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/nminchin/32/6911_2.png) [@nminchin](https://forum.inductiveautomation.com/u/nminchin)\ **Post date:** [May 16, 2022, 12:49pm UTC](https://forum.inductiveautomation.com/t/perspective-relative-references-to-parent-component-properties/59388/8 "2022-05-16T12:49:35Z")
Nah, they gave up/found it wasn’t viable last I heard. I don’t know what the reason was… to be honest, it doesn’t seem that difficult albeit a little time consuming. I’m sure when/if I get to it, I may run into hurdles 🤷‍♂️ I’m curious what the result will be though and if it’ll be worth the trouble at the end of it ---
**Author:** ![victordcq](https://avatars.discourse-cdn.com/v4/letter/v/f6c823/32.png) [@victordcq](https://forum.inductiveautomation.com/u/victordcq)\ **Post date:** [May 17, 2022, 6:10am UTC](https://forum.inductiveautomation.com/t/perspective-relative-references-to-parent-component-properties/59388/9 "2022-05-17T06:10:51Z")
Ah is script less performant than expression then? Im not to busy with that. What i did notice is that flexrepeaters are really slow, it gets really obvious if you give it a high number. So i assume all embdedded views suffer from this a little bit. We wanted to use a flex repeater to “draw” out a storage and have a view for each possible location. This worked decently in vision but was so slow in perspective, that i made a module for the company to draw out the storage. The performance improvement was insane. I guess like almost everything you can only choose 2 of the 3 Quality, speed, price ---
**Author:** ![pascal.fragnoud](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pascal.fragnoud/32/24728_2.png) [@pascal.fragnoud](https://forum.inductiveautomation.com/u/pascal.fragnoud)\ **Post date:** [May 17, 2022, 7:37am UTC](https://forum.inductiveautomation.com/t/perspective-relative-references-to-parent-component-properties/59388/10 "2022-05-17T07:37:44Z")
> [@victordcq](#): > > Ah is script less performant than expression then? There's the overhead of loading the interpreter, and I'm guessing expressions are also easier and faster to parse. ---
**Author:** ![victordcq](https://avatars.discourse-cdn.com/v4/letter/v/f6c823/32.png) [@victordcq](https://forum.inductiveautomation.com/u/victordcq)\ **Post date:** [May 17, 2022, 8:01am UTC](https://forum.inductiveautomation.com/t/perspective-relative-references-to-parent-component-properties/59388/11 "2022-05-17T08:01:56Z")
Oh, well its not something we notive here. We use scripting a lot. Or maybe that was one of the causes that the flex repeater also went super slow idk. ---
**Author:** ![pascal.fragnoud](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pascal.fragnoud/32/24728_2.png) [@pascal.fragnoud](https://forum.inductiveautomation.com/u/pascal.fragnoud)\ **Post date:** [May 17, 2022, 8:04am UTC](https://forum.inductiveautomation.com/t/perspective-relative-references-to-parent-component-properties/59388/12 "2022-05-17T08:04:20Z")
I’m pretty sure in most cases it’s not noticeable, but it’s something to keep in mind: If you can do it in an expression, might as well do that. ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [May 17, 2022, 11:35am UTC](https://forum.inductiveautomation.com/t/perspective-relative-references-to-parent-component-properties/59388/13 "2022-05-17T11:35:43Z")
> [@pascal.fragnoud](#): > > There’s the overhead of loading the interpreter Yes, quite significant. > [@pascal.fragnoud](#): > > expressions are also easier and faster to parse. Not parsed at execution time. They are parsed or deserialized once at tag/binding startup. Pure java method execution after that. No overhead, no interpretation. ---
**Author:** ![nminchin](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/nminchin/32/6911_2.png) [@nminchin](https://forum.inductiveautomation.com/u/nminchin)\ **Post date:** [August 4, 2022, 12:04am UTC](https://forum.inductiveautomation.com/t/perspective-relative-references-to-parent-component-properties/59388/14 "2022-08-04T00:04:54Z")
I just wanted to bump this again and see if anyone from IA can comment on the OP, and whether relative referencing can be made simpler and consistent? i.e. being able to address subsequent parents using either ```auto parent.parent.parent.custom.prop1 ../../../.custom.prop1 # or similar ``` instead of having to explicitly name them (which defeats the purpose of using relative referencing) ---
**Author:** ![nminchin](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/nminchin/32/6911_2.png) [@nminchin](https://forum.inductiveautomation.com/u/nminchin)\ **Post date:** [August 31, 2022, 1:09am UTC](https://forum.inductiveautomation.com/t/perspective-relative-references-to-parent-component-properties/59388/15 "2022-08-31T01:09:29Z")
Sad face ☹ ---
**Author:** ![jlandwerlen](https://avatars.discourse-cdn.com/v4/letter/j/bc8723/32.png) [@jlandwerlen](https://forum.inductiveautomation.com/u/jlandwerlen)\ **Post date:** [August 31, 2022, 1:12am UTC](https://forum.inductiveautomation.com/t/perspective-relative-references-to-parent-component-properties/59388/16 "2022-08-31T01:12:32Z")
Perhaps call out people from IA, put them on the spot, like @paul-griffith, @ggross @cmallonee🙂 ---
**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:** [August 31, 2022, 3:08pm UTC](https://forum.inductiveautomation.com/t/perspective-relative-references-to-parent-component-properties/59388/17 "2022-08-31T15:08:27Z")
This is about as much as I know: [https://files.inductiveautomation.com/sdk/javadoc/ignition81/8.1.19/com/inductiveautomation/perspective/gateway/property/PropertyReference.html](https://files.inductiveautomation.com/sdk/javadoc/ignition81/8.1.19/com/inductiveautomation/perspective/gateway/property/PropertyReference.html) This is a deep, fundamental piece of Perspective that I had no hand in, so I can’t speak as to _why_ any of this is the way it is. ---
**Author:** ![lrose](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/lrose/32/62724_2.png) [@lrose](https://forum.inductiveautomation.com/u/lrose)\ **Post date:** [August 31, 2022, 6:43pm UTC](https://forum.inductiveautomation.com/t/perspective-relative-references-to-parent-component-properties/59388/18 "2022-08-31T18:43:34Z")
So, as best I can understand it (which isn’t much 🤷🏻‍♂️ ) You start with `..` and then each parent container you want to traverse up the tree, adds another single `.` Or you can also use, `../`. Basically: Both `..` and `../` move the point of reference to the parent container. Once there you can move to the next parent with either a single `.` or `../`. Some examples. Say you have a structure of nested containers: ```auto root ->Parent 1 ->->Parent 2 ->->->PeerComp ->->->ThisComp ->->Parent 3 ->->->OtherComp ``` _ **Example 1** _ To reach a custom property on PeerComp in a binding from ThisComp then you would use the following. `../PeerComp.custom.prop1` The `../` places you in the point of reference of `Parent 2` Then you provide a valid _Property Identifier_ _ **Example 2** _ To reach a custom property on Parent 2 in a binding from ThisComp then you would use the following. `../../Parent 2.custom.prop1` or `.../Parent 2.custom.prop1` The first `../` from the property identifier puts you in the point of reference of Parent 2, as in Example 1, you can then use either another `../` or just `.` to put you in the point of reference of Parent 1. To be valid property identifiers must be of the form `..`, so you must traverse far enough up the tree to reference the component by name (e.g. the components parent). _ **Example 3** _ To reach a custom property on Parent 1 in a binding from ThisComp then you would use the following. `../../../Parent 1.custom.prop1` or `..../Parent 1.custom.prop1` This is just a continuation of example 2. For each parent that you need to traverse up the tree you add either another `../` or `.` So two dots to get to the parent of this component and then an additional dot for each parent up the tree. _ **Example 4** _ Finally, if you need to get to the root then just a single `/` can be used. Essentially this puts you in the point of reference of the View, so To reach a custom property on root in a binding from **any** component then you would use the following. `/root.custom.prop1` Finally, you can only use the _dot_ notation to travers up the tree, to come back down you must then use an absolute path. For instance, to reach a custom prop on PeerComp in a binding from OtherComp you could use the following. `.../Parent 2/PeerComp.custom.prop1` So all of that just to work through the Relative path prefix syntax. On top of this there is also, the Absolute path prefix type, which is as you might expect the path in reference to the View, and the Shortcut path prefix type, which is the _this, view, parent_ type paths. Basically, the Shortcut’s are exactly that named replacements for common paths. So _parent_ always takes you to the parent of the component you’re working with, _view_ always takes you to the view that you are working with, and _this_ is always to this component. So working with our example structure we can see that `parent.custom.prop1` is equal to `.../Parent 2.custom.prop1`. So you could say that `parent = .../parentName` In the same way, `this.custom.prop1` is equal to `../ThisComp.custom.prop1`. So you could say that `this = ../componentName` However, you can’t use `/` or `.` in a shortcut prefix, so for instance from OtherComp the path `parent/Parent 2/ThisComp.custom.prop1` is invalid. This is why, `parent.parent.*` doesn’t work. Instead you would need to use either the Absolute path `/root/Parent 1/Parent 2/ThisComp.custom.prop1` or the Relative path `.../Parent 2/ThisComp.custom.prop1`. The only thing left of note, is that “as far as I can tell” there is no relative path that will reach the view, so the only way to reach properties on the view is to use `view.custom.prop1`. Likewise the only way to reach properties on the root is to use an Absolute path `/root.custom.prop1`. ---
**Author:** ![Carl.Gould](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/carl.gould/32/7262_2.png) [@Carl.Gould](https://forum.inductiveautomation.com/u/Carl.Gould)\ **Post date:** [August 31, 2022, 8:20pm UTC](https://forum.inductiveautomation.com/t/perspective-relative-references-to-parent-component-properties/59388/19 "2022-08-31T20:20:27Z")
The answer provided by @lrose is pretty much textbook perfection. I don't really have much to add. I guess I can try to answer these original questions: > [@nminchin](#): > > Why is every level so different? > Why can’t I use `{parent.parent.parent.meta.name}` to get to the `view.root`? > Why can’t I use `{....../root.meta.name}` to get to `view.root`? The answers for these questions are essentially "because that's how we programmed it". The idea here was that the syntax was `{../locate/the/component DOT scope DOT property path}` We use shortcuts plus filesystem-style slash-based tree traversal syntax to get to the target component, and _then_ we use dots to get into the property namespace. This keeps the path parsing deterministic. > Why is every level so different? Is it? I don't think so. You have 1) direct keyword-orient shortcuts (this, parent, view, session, and page), you have "go up X levels from here", and you have "start at the top". > Why can't I use parent.parent.parent... We didn't want to overload the use of dot-dereferencing because that would have led to confusing and in some cases non-deterministic path parsing. If we allowed `parent.parent.parent.scope.path` it would also invite the syntax of `parent.parent.child.child.scope.path` that is - to use the dot separator to walk up and down the component tree. If we do that, it becomes difficult to determine when the "component path" bit ends and the "scope.path" bit begins. You'd be hosed if you had a component named "meta", for example. > Why can't I use `......./root` Well this is a bit of a curiosity due to our implementation. The root container is actually the top of the component heirarchy. The view is sort of special and not actually a component, so it's a bit of an outlier. I can understand that this might feel inconsistent, but that's just the way it is. ---
**Author:** ![richardNZ15](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/richardnz15/32/33373_2.png) [@richardNZ15](https://forum.inductiveautomation.com/u/richardNZ15)\ **Post date:** [October 6, 2022, 12:58am UTC](https://forum.inductiveautomation.com/t/perspective-relative-references-to-parent-component-properties/59388/20 "2022-10-06T00:58:16Z")
Why would Ignition throw an expression error for these relative references when i've picked the property from the property browser...? This is maddening. Property browser trying to configure a Property binding on a basic label component: ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/1/2/122fe05e432713fc1985dcad5df9fb4ebe1fd911.png) Path provided by Ignition, which makes sense based on the comments above.. ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/2/5/252c168bbe5302fdd7c43aaaff50ca07de5dd523.png) Binding doesn't work.. ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/c/f/cf1c90bd04cda112af647148f2ce51e3a13931e5.png) Different behavior when i use an Expression binding instead: ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/b/1/b1cf225c0ed5a7af0cc3c572ac0a26e74fbc4cee.png) ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/7/5/75a66b8166174660e189b45bb3dc1f347962949d.png) ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/4/6/460340275c5d053584cee2b771ae4228f74c8beb.png) [Next page](https://forum.inductiveautomation.com/t/perspective-relative-references-to-parent-component-properties/59388.md?page=2)