Make "Refresh Data" and "Ajax Refresh" needless and automatic

By Pedro Freire on 1 Apr
Just like you can rename identifiers (entity names, I/O/local variables, etc.) and have all their usages throughout the code be renamed instantly (from the point of view of the developer), identifier value changes (i.e., changes in variables, aggregates, etc.) could also be tracked when an action finishes on the same screen.

When this is the case, any parts of the screen that were rendered with variables, aggregates, etc. that were changed in the action should be AJAX-refreshed automatically. Aggregates refresh automatically if the primary keys that were changed are now on screen / are in the scope of the aggregate.

Tracking could occur either with a "dirty" flag for each variable/aggregate, or be performed after the action finishes on the same screen, comparing all screen widgets' variables'/aggregates' current values with the new values after the action finished (a bit like AngularJS v1 did).

I'm sure this is not as trivial as what I'm spelling out here, but this is the basic idea.

Eliminating these two ("Refresh Data" and "Ajax Refresh") would (IMHO) remove another roadblock for the "citizen developer" who will likely not be accustomed to being alert to disparate display/data refreshing requirements.

I have had plenty of occasions where this behavior would be cause problems. For example, some screens are very complex, and updating an entire table would be a performance killer when I just need to update one row. In other scenarios, I have deliberately mnipulated backing data without refreshing the screen because there was a purpose to it.

J.Ja?
On the first issue you describe, the system could also understand that and track that directly (unless you used your own SQL, but most simple parsing techniques will also figure that out), updating a single row on the table (or as little as possible, anyway).

The second issue I cannot respond to as you don't describe it in detail: if you update entities that are not displayed on screen, the screen should not be updated; but if you do update entity attributes that are on screen... why wouldn't you update the screen? But I must admit I am just learning OutSystems (little over 1 month hands-on experience) and can very easily be overlooking use cases. I welcome your comments.

Thank you.
Pedro -

There are just a few edge cases where you want to update data behind the scenes but not see it on the screen yet. Rare... but it's come up, especially in some circumstances where you are doing a lot of tuff in popups but don't want to write it to the DB until an actual save occurs on the base screen.

Also of note... the system does already work like this in some circumstances. If you use ListAppen/Insert/Remove on Table records, they carry an implicit refresh with them.

J.Ja?