# Perspective refresh binding by script without a message handler **URL:** \ **Category:** Ignition\ **Tags:** perspective\ **Created:** [May 9, 2024, 8:16pm UTC](https://forum.inductiveautomation.com/t/perspective-refresh-binding-by-script-without-a-message-handler/90189 "2024-05-09T20:16:19Z")\ **Posts on this page:** 15\ **Page:** 1
**Author:** ![Zach\_Larson](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/zach_larson/32/54388_2.png) [@Zach\_Larson](https://forum.inductiveautomation.com/u/Zach_Larson)\ **Post date:** [May 9, 2024, 8:16pm UTC](https://forum.inductiveautomation.com/t/perspective-refresh-binding-by-script-without-a-message-handler/90189/1 "2024-05-09T20:16:19Z")
I see one way to refresh my table data binding is with the message handler. [How to trigger SQL Query on request? - #9 by pturmel](https://forum.inductiveautomation.com/t/how-to-trigger-sql-query-on-request/88775/9)] Can I call for a binding to be refreshed by a button's script without using a message handler? * * * Update: Found it ```python myTable= self.parent.parent.getChild("flexDataTable").getChild("Table") myTable.refreshBinding("props.data") ``` Found it here: [How to refresh binding after clicking button on popup - #4 by ShaneH](https://forum.inductiveautomation.com/t/how-to-refresh-binding-after-clicking-button-on-popup/67515/4)] ---
**Author:** ![Transistor](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/transistor/32/3380_2.png) [@Transistor](https://forum.inductiveautomation.com/u/Transistor)\ **Post date:** [May 9, 2024, 8:24pm UTC](https://forum.inductiveautomation.com/t/perspective-refresh-binding-by-script-without-a-message-handler/90189/2 "2024-05-09T20:24:23Z")
Sure. Something like, `self.getSibling(“TableNameHere”).refreshBinding(“props.data”) But why not make your development more robust by using message handlers? ---
**Author:** ![Zach\_Larson](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/zach_larson/32/54388_2.png) [@Zach\_Larson](https://forum.inductiveautomation.com/u/Zach_Larson)\ **Post date:** [May 9, 2024, 8:32pm UTC](https://forum.inductiveautomation.com/t/perspective-refresh-binding-by-script-without-a-message-handler/90189/3 "2024-05-09T20:32:02Z")
I think the message handler is the less robust. * * * ~~I had an issue getting the refreshBinding to work in a single line.~~ I had placed something wrong the first time. ---
**Author:** ![Transistor](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/transistor/32/3380_2.png) [@Transistor](https://forum.inductiveautomation.com/u/Transistor)\ **Post date:** [May 9, 2024, 8:38pm UTC](https://forum.inductiveautomation.com/t/perspective-refresh-binding-by-script-without-a-message-handler/90189/4 "2024-05-09T20:38:57Z")
The getParent, getNephew, getCousin syntax is very brittle. Move an item or use Designer's "Wrap in Container" context menu option and your application is broken. Editing it and tracking what exactly the path is pointing to is painful. The message handler is a one-liner and can be a one-liner on the sender and receiver. ---
**Author:** ![Zach\_Larson](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/zach_larson/32/54388_2.png) [@Zach\_Larson](https://forum.inductiveautomation.com/u/Zach_Larson)\ **Post date:** [May 9, 2024, 8:40pm UTC](https://forum.inductiveautomation.com/t/perspective-refresh-binding-by-script-without-a-message-handler/90189/5 "2024-05-09T20:40:15Z")
Doesn't each message handler create a listener? I tried to write this second concern I have many times. I want the receiving part to be restricted from changing or behaving differently. Receiving the message handler can be changed or different tomorrow. ---
**Author:** ![Transistor](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/transistor/32/3380_2.png) [@Transistor](https://forum.inductiveautomation.com/u/Transistor)\ **Post date:** [May 9, 2024, 8:42pm UTC](https://forum.inductiveautomation.com/t/perspective-refresh-binding-by-script-without-a-message-handler/90189/6 "2024-05-09T20:42:23Z")
I think it's covered pretty well in the IU video on the top of this page: > **[Component Message Handlers | Ignition User Manual](https://docs.inductiveautomation.com/docs/8.1/ignition-modules/perspective/scripting-in-perspective/component-message-handlers)** > > In Perspective, Component Message Handlers are the preferred way to pass parameters between components or Views. Doing this involves the system.perspective.sendMessage function. There are typically two steps involved: ---
**Author:** ![Zach\_Larson](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/zach_larson/32/54388_2.png) [@Zach\_Larson](https://forum.inductiveautomation.com/u/Zach_Larson)\ **Post date:** [May 9, 2024, 8:53pm UTC](https://forum.inductiveautomation.com/t/perspective-refresh-binding-by-script-without-a-message-handler/90189/7 "2024-05-09T20:53:23Z")
I was still trying to edit my post. I find it hard to describe, but I don't like the way the message is received could be changed. I like when only the sending side controls the behavior. If it has to be disconnected, then I would rather write to a view or session property because at least then, I know that nothing is going to misinterpret the writing, at least reducing complexity some, one less whole set of things to check or maintain further complicated with using more embeds with more message handlers. They are useful, but if possible where possible I like the smaller footprint so I don't worry about it in the middle of the night on vacation. ---
**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:** [August 22, 2024, 3:21pm UTC](https://forum.inductiveautomation.com/t/perspective-refresh-binding-by-script-without-a-message-handler/90189/8 "2024-08-22T15:21:23Z")
> [@Zach\_Larson](#): > > I don't like the way the message is received could be changed. > I like when only the sending side controls the behavior. What ? Why ? I find it's much more logical to have the receiving end handle the behavior. Not only it makes more sense to have a component handle its own thing, but it also centralizes the logic. ---
**Author:** ![Zach\_Larson](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/zach_larson/32/54388_2.png) [@Zach\_Larson](https://forum.inductiveautomation.com/u/Zach_Larson)\ **Post date:** [August 22, 2024, 3:43pm UTC](https://forum.inductiveautomation.com/t/perspective-refresh-binding-by-script-without-a-message-handler/90189/9 "2024-08-22T15:43:43Z")
Sorry typo, meant when only the requesting side, the binding, controls. Edit\* I got the requesting conflated with the receiving, and said sending on accident. I can't find the right word, requesting is not precise enough really, but it is not the sending or receiving as the message handler is both those things. A message handler is like a middle man. I mean to specify the actual object with the request/binding. Sometimes I have to use 1 to many. Sometimes 1 to many is fewer parts to break and lower overhead. I have to use it, using 1 to many is what it is. If I can choose, I like 1 to 1. I want to see all the information on the object that is changing. I don't want to have to guess what is changing the thing. I don't want to worry about how objects will interact when adding new objects. I have pages with embeds and message handlers. I have pages writing to view and sessions. It isn't always avoidable. I try to keep small footprints for robustness. Like the newest rockets, the fewer parts, the fewer things that can break, and lower overhead. Sometimes a message handler is fewer things though. Anyway, at the end of the script, I just wanted to refresh the table, not tell a middle man to refresh the binding then for the middle man to then refresh the table's binding. Though it is splitting hairs on if the object will be moved or if the message handler will be change to interact with more things. Probably justifiable both ways. Except if it is a vendor, then I think they would just always use the message handler in every case, because they are 100% going to move the objects and change the message handler. ---
**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 22, 2024, 5:31pm UTC](https://forum.inductiveautomation.com/t/perspective-refresh-binding-by-script-without-a-message-handler/90189/10 "2024-08-22T17:31:10Z")
> [@Zach\_Larson](#): > > not the sending or receiving as the message handler is both those things Ummm...No. A message handler is just a handler. It says, when I _receive_ this message, I do this thing. That's it, that thing could easily be sending another message, but the handler it's self is only ever the receiving end of a message. > [@Zach\_Larson](#): > > I don't want to have to guess what is changing the thing. You don't. The message handler can be on the thing. > [@Zach\_Larson](#): > > I just wanted to refresh the table, not tell a middle man to refresh the binding then for the middle man to then refresh the table's binding This is a perfectly acceptable approach, it is brittle though, because even just ungrouping it could potentially break it. Copy and Paste requires you to go in and edit the component. All kinds of things like this can cause the code to need to be corrected. With the handler approach all you need to do is send the message. The suggested approach changes the call to `refreshBinding()` with this: ```python system.perspective.sendMessage('refresh') ``` And a message handler like this: ```python def onMessageReceived(self, payload): self.refreshBinding("props.data") ``` You propagate that to any component that you want to refresh and your done. Doesn't matter what the "path" to that component is, it will always refresh. I'll also add that IMHO, this is also easier to read. ---
**Author:** ![Zach\_Larson](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/zach_larson/32/54388_2.png) [@Zach\_Larson](https://forum.inductiveautomation.com/u/Zach_Larson)\ **Post date:** [August 22, 2024, 5:33pm UTC](https://forum.inductiveautomation.com/t/perspective-refresh-binding-by-script-without-a-message-handler/90189/11 "2024-08-22T17:33:11Z")
Thanks Does each message handler create another listener? ---
**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 22, 2024, 5:36pm UTC](https://forum.inductiveautomation.com/t/perspective-refresh-binding-by-script-without-a-message-handler/90189/12 "2024-08-22T17:36:39Z")
Perhaps in the bowels of the Java on the gateway this is how it works, I’m not sure, haven’t ever needed to dig into that. Why would that be important? ---
**Author:** ![Zach\_Larson](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/zach_larson/32/54388_2.png) [@Zach\_Larson](https://forum.inductiveautomation.com/u/Zach_Larson)\ **Post date:** [August 22, 2024, 5:45pm UTC](https://forum.inductiveautomation.com/t/perspective-refresh-binding-by-script-without-a-message-handler/90189/13 "2024-08-22T17:45:14Z")
Don't listeners bog down threads making the UI sluggish? Sorry to answer a question with a question. I do not know for sure. ---
**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 22, 2024, 7:34pm UTC](https://forum.inductiveautomation.com/t/perspective-refresh-binding-by-script-without-a-message-handler/90189/14 "2024-08-22T19:34:03Z")
> [@Zach\_Larson](#): > > Don't listeners bog down threads making the UI sluggish? You would have to have many before that would ever come into play. There are other more direct targets for performance to watch out for (e.g. nested embedded views, massive script executions, etc...) If I were seeing poor performance this would be the furthest thing from my mind. ---
**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:** [August 23, 2024, 6:28am UTC](https://forum.inductiveautomation.com/t/perspective-refresh-binding-by-script-without-a-message-handler/90189/15 "2024-08-23T06:28:07Z")
The one thing I'd watch out for with messages is the flow of execution. Keep in mind that a call to `sendMessage` is not blocking. > [@Zach\_Larson](#): > > not tell a middle man to refresh the binding then for the middle man to then refresh the table's binding If you delegate the resfreshing handling to the table itself by placing the message handler in its scripts... it becomes its own middle man. And now if there are things that should happen when the table is refreshed, you can include them there. Maybe you flash the row that was just updated in bright colors, or you check a particular column for specific values... But the "outside" doesn't need to know about it, it just asks the table to refresh itself and lets it do its own thing.