Hello,
I am running up against an issue where I have a table populated by a database query with several columns. One column I am rendering as a toggle and performing an update query on commit and it seems happy enough. But I didnt like the having to click to start cell commit (slightly clunky when using just a toggle) so like all programmers with a God complex (I created this one screen world, I will change anything to be how I wish) I created a view with a toggle, added the table params like value, row, column, etc., and rendered it in my table column using viewPath. Then I bind the input param 'value' to the toggle 'selected' and on render it looks right and the single click to change looks nice and smooth. I then have a changeScript on the 'selected' value on the toggle which tries to perform the update query.
The problem occurs if I need to revert the toggle value to its pre-user clicked value (say the update query fails). I can make logic to update the selected value back to the original (pre click) value, but then that triggers the changeScript and an infinite loop. I tried to do some debounce actions by adding a custom view property that would set to false when user clicks and then if the update succeeds back to true or after revert sets back to true, but it didn't seem to work. After trying this a few times the loop caused my gateway to crash and restart.
Because this doesn't happen with the vanilla table rendered boolean toggle using the edit commit I'm using it for now, but I was curious is anyone out there tried something similar and found a way around it. I'll admit I got stuck in an infinite loop myself for a while trying to figure it out 
IA threw an origin value into the changeScript that tells you the context the change was made from. Nesting your script in an if block that checks origin == 'Browser' should fix this issue for you.
Welcome to the forum, jj.
Tip: use paragraph breaks to break up your wall of text!
That did the trick! The action is nice and smooth now 
Thank you!
I understand you may want to keep things the way they are, but I prefer having a validation button to send the updates to the database, instead of sending one on each change2. .
The way I do it is by having a custom property pull the data and hold it, then binding the table to that custom prop.
Then, you can compare the data in the table and the original data in the custom property to find what changed (store the id in an invisible column), so you bulk insert/update just that.
If the operation fails (or when clicking a "reset" button, or whenever you chose), you can just call refreshBinding on the table's data to revert it to its original state.
Calling refreshBinding on the custom property will re fetch the data from the db and update the table as well (reverting any change made to it and not saved)
It solves a few issues:
- The one you described
- If a user changes a value, but leaves the page without committing (he doesn't even know it has to be committed), it's never sent to the db. The "send of button click" method fixes that as well
- I find it easier to manage the global state of the table like this. What happens if a user changes 2 values in a row, but the 2nd one is rejected ? You may be left with an invalid state.
The only cons I can see:
- It requires one more click
- It may be harder (sometimes impossible) to keep the valid update and reject the invalid ones. If one row fails for some reason, it may be very hard to make the other ones stick.
2 Likes