Avoid using preparation data in screen actions\

it is said : "Avoid using data created in the screen preparation in the screen actions. For instance, instead of using the tablerecord record data, use only the ID of the row and fetch the data from the database again is needed"

tablerecord record »?! what is this? 

Can you clarify the last line as well, please.

I see that many developers CALL the preparation data in the SCREEN ACTIONS. For example, they use SQL blocks in the preparation and then in a SCREEN ACTION they put the SQL blocks again and refresh them connecting to the preparation data. Isn't this against the rule for a good performance?

Thanks in advance.

Hi Jorge,

Where are you reading that?


Hi Jorge,

Although I cannot comment on the technical veracity of what is claimed on that page, I've never seen performance problems caused by using preperation data in screen actions. That said, I may just have never come across a use case where that mattered.

As for your question "tablerecord record »?! what is this?", this refers the common use case of fetching a set of records from the database in the Preperation, and using a TableRecords widget on the screen to display that data (the TableRecord's Source Record List property typically set to the output list of the query). Say you have a screen action that is triggered by a button or link inside each row of the TableRecords. What OS suggest in the article you linked, is that in case you need data from that row (i.e. several columns), instead of using e.g. MyTableRecords.List.Current.MY_ENTITY.MyAttribute1, you fetch the data you need from the database again, based on the main Id of the current record.

As the page says...

Page size affects usability since it will increase the time to submit a form. If you use screen preparation data on screen action, that data will be saved on the page viewstate. Since the viewstate is a part of the page it is sent to the client with every requested page. The viewstate is also sent to the server on a post, postback and AJAX request. So avoid using preparation data in screen actions otherwise the size and loading time of the page can increase dramatically.

I think most of the case yes. So the viewstate is like a 2 way burden both client and server way, in the other hand requesting data again using sql would be like 1 way data transport to client and would not be in viewstate. You could explore it more by using Analytic in lifetime and look at page size.

For complex logic and complex UI it could be a point.

Well done Eric.

But if I need some data in screen action, from where should I get that.

Shall I replicate Aggregates in Screen Action?

Yes for best practice I think better to re-execute a query. But my guess is most of OS developer will not care about this...This would come later at tuning phase or consider this earlier for complex screen that might be using large data.

Suraj Borade, if you want to reduce the size of the viewstate, you should use the Refresh Data node, or use data coming from a screen widget.

You shouldn't have to replicate aggregates in screen actions, because the Refresh Data will reuse the same query defined in the preparation. If you cannot use the Refresh Data, that would be because your query is slightly different. In that case, I see no other option other than replicating the aggregate, and then changing it to suit your needs.

It's not too frequent to have performance problems with viewstate size, because OutSystems already does an excelent job on optimizing it. Besides, most screens don't handle large amounts of data at once. I believe that's why most developers don't care, or don't even know about this best practice.

Even when performance problems do occur, they're never easy to diagnose, so most teams would re-engineer the problematic screen, without even finding the root cause of the problem.

Hi Leo!

I believe what was not clear (at least for me) was that sentence: "instead of using the tablerecord record data". You said that we should use the Refresh Data node, or use data coming from a screen widget. I found it too. However it was not clear whether this tablerecord record data refers to the source variable bounded to the widget or the record data variable of the widget. 

It is important to be clear that using data coming from a screen widget will not save anything on the viewstate. This only happens if you use data declared from screen preparation (records, list records, aggregates...). Please correct me if I'm wrong in any way.

Hello André!

What I meant with "data coming from a screen widget" was something like a user input or combo box. The data of these widgets do not need to be stored on the viewstate, because on every request the user overwrites it anyway. I should have made it clear on my first answer.

Using data from the widget (a record from TableRecords1.List) or from the variable/aggregate that is the source of the widget (something like GetData.List) is the same thing - as far as viewstate is concerned. What gets stored on the viewstate is everything that is needed on subsequent requests.

Imagine that you have a query on the preparation called GetUsers, and render it on a table records called UsersTable. On a click of a button you need to send an email to a user (you will need the User.Email field). You have three options.

1. Use UsersTable.List.Current.User.Email to retrieve the email of the user. But this information was displayed on the previous request. It will be stored on the viewstate to bridge the gap between the display and its use to send an email.

2. Use GetUsers.List.Current.User.Email to retrieve the email of the user. But the query was executed on the previous request. So it will also need to be stored on the viewstate, to bridge the gap between the query execution and its use to send an email.

3. Use UsersTable.List.Current.User.Id to retrieve the User record from the database, and use its email. In this case, the email is being fetched from the database in the same request as being used to send the email. So it does not need to be stored on the viewstate. Note, however, that the Id will still need to be stored on the viewstate, for the same reasons as described before.

Option 3 is the one that is advocated by the performance best practice that Jorge Almeida was initially referring. It tells you to just use the id and fetch the data from the database again.