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]
Can I call for a binding to be refreshed by a button's script without using a message handler?
Update:
Found it
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]
Sure. Something like,
`self.getSibling(“TableNameHere”).refreshBinding(“props.data”)
But why not make your development more robust by using message handlers?
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.
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.
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.
I think it's covered pretty well in the IU video on the top of this page:
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.
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.
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.
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.
You don't. The message handler can be on the thing.
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:
system.perspective.sendMessage('refresh')
And a message handler like this:
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.
Thanks
Does each message handler create another listener?
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?
Don't listeners bog down threads making the UI sluggish?
Sorry to answer a question with a question.
I do not know for sure.
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.
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.
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.