I have been creating a multi-layered embedded view component to dynamically populate a Flex Repeater with user-input values. The goal is to create a component that dynamically reflects database table rows, allowing for edits and additions to said table.
This worked nicely until I started working on the change scripts. I found that when additional instances are added to a Flex Repeater (for instance going from 3 instances to 4) triggers a "Browser" change event on the Flex Repeater instance parameter, even when the changes are via scripting. Note, it isn't being triggered when I remove an instance via script. The goal was to use the "Browser" origin change script event on the instances to trigger table updates, but these events are causing me a headache. I tried filtering the events out, but it sometimes triggers more than once.
I was thinking about reporting this as a bug, but thought it safer to first see if this is expected behavior and if anyone knows a work around?
Note, we have already considered switching to a separate save button instead of save on change event, which wouldn't have this issue, but that has a lot of ramifications we are trying to avoid with this approach.
Hello Michael_Lindon,
Using the "Browser" origin change script event on the instance would be a headache to implement. What I suggest is to implement these updates with message handlers. You can use a message handler to trigger an update to refresh the bindings on the component you are working with. I have linked the documentation below on how you can further implement message handlers and refresh bindings for your project.
https://docs.inductiveautomation.com/display/DOC81/Component+Message+Handlers
https://docs.inductiveautomation.com/display/DOC81/Perspective+Component+Methods#PerspectiveComponentMethods-RefreshingBindings
I have considered messaging, but I feel they can easily cause unintended consequences and are difficult to trace the source should an issue occur, especially in the case of using multiple components on the same view. I do a lot of component re-use, to the point that most user views are 100% embedded views, so I tend to avoid them. Though I am open to convincing.
I created a bug ticket, since template repeaters shouldn't trigger a browser change event on instance creation when changed using script and will let the will of the Inductive Automation devs do as they will with it.
For my specific issue, I ended up switching tactics entirely and switched to a trust the developer approach for this situation. The solution was to add a hasChanged param and a set of togglable parameters that activate the CRUD actions, for instance a toggle that will create, delete, refresh, etc. Hope this gives flexibility to our development team to use the component as needed and gives new ideas to those interested.
Cheers.