Hello everyone.
I'm studying the platform and I encountered a situation that I couldn't understand completely.
Maybe we can discuss and propose a change in this (Performance Best Practices - Logic) article.
Here is the part I haven't understood (underline):"Avoid using queries inside ‘If’ branches in preparation
Description
Avoid using the conditional queries in preparation to prevent the extra query data from going to the viewstate.
Solution
When using refresh screens, take care with conditional queries (queries in "if" branches). To prevent this, declare a local screen variable and assign it from the query and with an empty record list in the beginning of the preparation.
Importance
If a query is only executed inside an "if" branch in the preparation and used outside that branch (in a table records, for example), its data need to be always in viewstate. This is because the query is only executed sometimes. This increases the page viewstate size.
Remarks
Note that this only happens if we use the submit action that terminates with an end node (causing the screen to refresh). For AJAX actions and for destinations, this does not apply."
I understand that we should declare a local variable (record list) at the preparation's beginning. But how are we going to assign values to this local variable without an aggregate in the preparation? Or the goal here is only to get rid of the aggregate inside an 'if' branch? Should we have a screen action querying the data?
Hi Lopes,
the solution doesn't suggest you get rid of the query inside the if, sometimes that just is what you want to do, but it proposes that you avoid the large viewstate in case of submit by adding an extra local list variable holding either the query results or empty list, to base all your UI on.
Alternatively, if it's a fast query, there might not be much harm in always executing it, dependent on the situation.
Dorine
Hey Dorine, thanks for your reply.
Does that mean that local variables aren't sent to the ViewState?
I have very little experience with traditional, was just giving my interpretation of the text.
But this is definitely worth an experiment, I would say.
You could set that up, or else I'll find some time next weekend.
Or has anyone else on the forum tried this out already ??
Hi Lucas,
First of all I want to say that I really appreciate your question! I had this doubt on the past. But after I tried this "Logic" best practice I could really see the benefit, specially, for application's with high volume data / complex data models - with a lot of attributes.
First of all let me answer your question:
Second point:
I already had the chance to apply this practice on some of the projects I've worked, and I could see the substantial benefit / impact it had on the performance of Traditional Web Apps, specially when you are dealing with complex / high volume data applications.
I really recommend a study and analysis of this best practice before someone starts using the "Submit" method on actions.
I hope you find this helpful!
Best regards,
Hi Lucas!
Dorine's interpretation is absolutely right! It's actually on point.