Hi All, I wanted to go over how the current iteration of auto refreshable fields and how the triggering works with some example scenarios and what has changed, as well as some ideas of how to further the functionality going forward.
Let’s start with a simple scenario, in which we have a dialog that has three fields:
The first field is a dynamic drop down, it is set to auto-refresh, and it is also set to trigger auto refreshes.
The second field is a text box that is also dynamic, is set to auto-refresh, but does not trigger auto refreshes.
The third field is another text box that is dynamic, again set to auto-refresh, and does trigger auto refresh.
Previous to 188.8.131.52, when choosing a value from the first drop down, both the second field and the third field would update, and they would try to do so immediately. In this case, it’s not much of a problem, because the two fields are independent. The area where we ran into problems was when the third field relied on information from the second. Sometimes, the second field wouldn’t be finished processing in order for the third to have the correct data to do its calculations. This is where the idea of cascading auto refresh came from originally.
After 184.108.40.206, the behavior for changing the first drop down stays the same: both the second field and the third field will update, however they will do so sequentially, so it is guaranteed that the third dialog field runs after the second.
The difference in behavior lies in if we manually changed the third dialog field text box which is set to trigger an auto refresh. Previous to 220.127.116.11, the first element would then update as it is set to auto-refresh, and the third dialog field is set to trigger auto refreshes. Post 18.104.22.168, however, because of the cascading auto refresh, this is no longer the case. Fields can only refresh other fields that come after them in a top to bottom order, and then left to right through tabs. This is the current way that we decided to enable multiple fields to depend on each other without the user being able to accidentally create a circular reference and then the appliance hanging.
Obviously, this can cause issues for customers upgrading, as the ordering of the dialog fields may need to change based upon the expected behavior of the automate methods/dependent dialog fields. At the time we felt that the large boost in functionality was worth the trade-off of potentially having to reconfigure dialogs.
In the future, we are planning on revisiting this design to be able to essentially “group” things together so that running a dialog doesn’t just go through the list one by one, but that each field can target specific other fields to refresh and/or respond to refreshes. This will again require a reconfiguration of existing dialogs, but hopefully will lead to even greater flexibility and functionality within the dialog itself regarding auto refresh.
@gmccullough If you have anything to add that I forgot, please do so