Avoid using preparation data in screen actions\

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?

Regards,
Thomas

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.