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

On our radar
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.

Created on 1 Apr 2016
Comments (6)
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.

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.


The main issue, confusion, and annoyance with the OS behavior is the paradigm that all "Refresh" operations are full blown Submit or Ajax operations tied to Server Side data.

My guess is that since OutSystems is an older product and initially they had to support non javascript browsers and javascript browsers.  Thus the dedicated Ajax Refresh operation for javascript browsers was a feature to break away from full blown submit needed for non javascript browsers.

The single page application paradigm wires in behind the scenes html control updating to local browser variables (not server variables).  There no need to go to the server to turn of series of controls off and on based on the value of another control with a modern browser.

When changing the value of checkbox, with other controls bound to the checkbox.value, OS should be able identify form bound variables and automatically update the page in place on a modern browser and also automatically perform a submit for non javascript enabled browsers.

The ajax refresh  should be the special case to perform requery server side data and form state.

Since P10, I think one of the main issues is that on Mobile, there's no Ajax refresh and everything tied to the screen refreshes automagically. So developers would perhaps expect that to be the case on web as well, but there may be performance penalties since there's communication with the server (on mobile, it's all local).

Erik -

You are right but for the wrong reasons.

Single page applications didn't exist when OutSystems was first created (15 years ago or so). The architecture didn't exist for it, and not JUST because you couldn't count on JavaScript being enabled. Now the team has to choose between "radical departure in design that either breaks existing apps or splits 'how we do things' and takes a ton of time" and "building new features into the platform".