I have a "home screen" with a flex repeater containing many instances of a certain sub-view. This sub-view itself has any number of sub-views, whether in flex repeaters, embedded views, or otherwise.
On the top level home screen, sometimes I execute a "refreshBinding" on props.instances of the main flex repeater. But I am finding this does not propagate down to other bindings contained in the bowels of the other views, so to speak. And I can't fire a refreshBinding on everything at once, because depending on the timing of everything, this sometimes leads to good results and sometimes bad results. A "bad result" is when I refresh the overarching flex repeater successfully, but individual instances of that flex repeater do not refresh some of their bindings at the right time, leading to the wrong text appearing on the wrong instances... that kind of idea.
What I think I need (?) is to refresh each necessary binding one by one, down the chain, from top level flex repeater down to the granular sub-views therein, and it must happen in a specific order. The root cause of all of this is that bindings with script transforms don't seem to refresh ever unless this refreshBinding command is fired specifically to that binding (over-arching views being refreshed do not propagate down). If I have a sub-view with a binding including a script transform, it is tough to ensure this script transform refreshes unless I get cute with cascading message handlers, do something creative with invokeLater, etc... I feel like I have programmed myself into a corner here. system.perspective.refresh() does not work because I have found this won't refresh bindings with script transforms.
Has anyone found themselves in a similar situation and come up with something elegant? I want to go the "best practice" route for sure here but I do not even know what that might look like...
If more details are needed to understand what I mean, I can definitely provide.
You'll probably have to post more detail. I suspect that your flow of data isn't "forward" into your nested elements. Within any one view, data should flow in bindings basically unidirectionally: view params => view custom => component custom => component props. Keeping in mind that parameters for nested views are component props in their parent views.
The only "reverse" data flows should be
bidirectional bindings on user input fields' component prop to view custom props, or
scripted assignment to props as a result of a user action (not due to binding eval).
I suspect you have reverse data flows that aren't one of those two.
You're absolutely right, I definitely have one or two "reverse data flows" that seemed inconsequential at the time but now are clearly not ideal. That information on proper data flow is golden though, I want to write it in a little notebook that has a lock and key and everything. I'll take another stab at things and follow back up here later on... Thank you for the response.
This makes me wonder, though -- I noticed earlier that view parameters can be changed from "input" to either "output" or "input/output". I have never used anything here except "input" and I am thinking this could be the solution I need. Either way, I'll just have to keep playing with it.
In my data flow recommendation, some clarifications:
any "downstream" property group can pull data from its own group, too, as long as you maintain some kind of "forward" flow within each group. Circular bindings are very bad.
In/Out parameters can be used with bidirectional bindings (in both parent and child views) to connect inner input fields to outer custom props, possibly also inner scripted writes to outer custom props.
Out parameters have to flow completely in reverse. (I avoid these.)
Treat session custom props like view input parameters, but you can also bidirectional bind back to them, or use scripted writes.
They do. When whatever they're bound to updates, the binding reevaluates.
What's in the script does not trigger refreshes, but if reevaluation depends on something that's pulled in the script, you should change it to use a structure binding instead.
Whenever I want a binding update to trigger when any number of values are changed, like in this table data filtering example, I use an Expression Structure Binding.
This ended up being the nugget of wisdom that solved my problem. I had the "problem binding" bound to something that does not change from workcell to workcell. So when the instances refresh and change around and everything, that one specific binding had no idea this was happening at all. I just had to reconfigure the binding to something that does reliably refresh during these overarching refresh events (i.e. the overarching workcell rather than the individual station number), refactor a couple lines of the script transform, and it is working great now. But I am just amazed at the responses in this thread in general, just a ton of rock solid information. Thanks to all who replied!!
