View state in OutSystems Applications

João Proença

Discussion

Hi everyone,

I'm going to talk here about a portion of our Web Screens that a lot of times we don't even know is there: the view state.

What is the view state?

The HTTP protocol is stateless, which means that each request is treated as an independent transaction that is unrelated to any previous request.

To overcome this protocol limitation, we use the view state, which is an hidden portion of the rendered web page where local variables are stored. This data is sent back to the server when the user clicks a button on a page (Submit), and is the information the server will use to know the state of these variables.

What is inside the view state in OutSystems Applications?

The OutSystems Platform has optimization mechanisms in place to decide which Web Screen variables should go to the view state. In general terms, Web Screen or Web Block variables that are used in screen actions (for instance in assign nodes or as parameters to other actions) should be selected by the Platform to be included in the view state. The rationale behind this is that when a postback request reaches the server and variables will be involved in the logic, we must know what is the state of those same variables as they are being seen by the user (and which can be different from the original value when the Web Screen was loaded in the "get" request).

The following Microsoft article gives you more information about the view state in a web page's lifecycle:
https://msdn.microsoft.com/en-us/library/ms972976.aspx

What are the dangers of the view state?

We must always pay attention to not create a combination of screen actions and web screen variables that will result in a lot of data being included in the view state. This is important because a large view state degrades the performance of a web page and, in certain network configurations, can even result in runtime errors because of policies that limit the maximum size of the view state in a web request.

A common case of this sort of problem that happens frequently is a view state that becomes very large because of a record list being included in it. One example of this can be seen in the attached eSpace, which has a simple screen where you choose an eSpace from your factory and two buttons, each one leading you to another screen where you can download some of the published versions of that eSpace.

The EspaceVersionsInViewstate screen will query the database in the preparation to fill out the EspaceVersionTable widget Source Record List in the screen with all the contents of the eSpace Versions.

When you press one of the download buttons in that Table Records, the associated action will redirect you to a Download node that is fed by the binary data that is in the Record of the current element of the widget’s Record List. This will force it to be included in the view state, since the data is being obtained directly from the widget's Record List and its state is maintained by the browser.

In this situation, if you check the source code of the EspaceVersionsInViewstate page in the browser (by using the "Open Source Code" option present in most browsers), you will see that there is a very large binary-encoded string in the beginning of the <body> HTML tag (check below image):

This is the _OSVSTATE variable where we store the view state at the browser level. As you can see, it has a large size because all of the eSpace binaries for each version in the Record List are being encoded in it.

The test eSpace also contains the EspaceVersionsNotInViewstate web screen, where we use a different approach for the same functionality. If you check the DownloadVersion action, it now has an EspaceVersionId input and the Download Node obtains the eSpace version binary from a database query. In this case, since we are not obtaining the binary directly from the EspaceVersionTable Source Record List, the platform decides it is not necessary to include it in the view state.

The below image illustrates the differences between these two implementations of the same functionality:

If we check the source code of the EspaceVersionsNotInViewstate web screen when opened in the browser, you will see that the _OSVSTATE value is now much smaller than the previous case:

Hope this helps you all debugging your view state problems!

Cheers!
João Proença

TestViewstate.oml

08 Jul 2013

Justin James

MVP

Thanks! View State has given us some problems in the past on a couple of items which has forced us to take some... erm... "unique" workarounds.

J.Ja

09 Jul 2013

carl ruhle

good explanation, but there are some pictures missing.

where I work, we are having some problems with this matter.

cr

09 Mar 2015

Bruno Gonçalves

Why are there two occurrences of the viewstate in the page (when inspecting the html)?

23 Feb 2017

Wim van den Brink

VIEWSTATE is the asp.net implementation of the view state, _OSVSTATE is the OutSystems implementation, to prevent messing each other up I presume OutSystems has its own implementation which runs after the the ASP processor.

09 May 2017

1 reply

10 May 2017

Show thread

Hide thread

Bruno Gonçalves

Wim van den Brink wrote:

Sorry for not getting into the specifics, but basically there's a hidden variable at the end of the page:

<input type="hidden" name="__OSVSTATE" id="__OSVSTATE" value="xxxxxxxxxxxxxxxxxxxxxxxxxxxxx" />

and then via $(document).ready the variable is loaded with the exact same content:

<script type="text/javascript">outsystems.internal.$._waitForViewstate = true;outsystems.internal.$(document).ready(function() {outsystems.internal.$('input[name=__OSVSTATE]').val('xxxxxxxxxxxxxxxxxxxxxxxxxxxxx');outsystems.internal.$._waitForViewstate = false;});</script>

If the variable already holds the value why do they have to overwrite it through the ready function?

10 May 2017

Sridhar Sivaprakasam

During a screen development and during publish, i got an error saying more than 64000 variables are not allowed/ exceed 64k variables. We are using java implementation. Is this because of view state or different?

09 May 2017

3 replies

Last reply 10 May 2017

Show thread

Hide thread

Justin James

MVP

Sridhar Sivaprakasam wrote:

It's because of viewstate. Java has a limit.

Please reach out to me internally, since we work for the same company and it's my job to help folks with these kinds of issues, and I'll help you solve this problem. usually when you see this limitation, it is due to a poor UI design or a mistake in the screen's architecture. And the workarounds to allow big viewstates end up causing performance problems.

J.Ja

09 May 2017

Wim van den Brink

Justin James wrote:

Sridhar Sivaprakasam wrote:

It's because of viewstate. Java has a limit.

J.Ja

I really would like to see a screen resulting in more as 64k vars :-D , must be some kind of editable grid implementation?

10 May 2017

Sridhar Sivaprakasam

Wim van den Brink wrote:

Justin James wrote:

Sridhar Sivaprakasam wrote:

It's because of viewstate. Java has a limit.

J.Ja

I really would like to see a screen resulting in more as 64k vars :-D , must be some kind of editable grid implementation?

Hi Justin,

Its our Application Review screen, where we display complete information about a customer's application, bureau, applicant, fraud, co-applicant information. We have 10 web blocks in it as a different sections.. :)

Unfortunately, we have such kind of screen. Out OOB implementation + customer requirement exceeds the limit. I used a popup editor to fix this..

Thank you,

Sridhar. S

10 May 2017

Rebecca Hall

We were having some issues with view state too, a couple of helpful things we found in troubleshooting:

Performance CSI Forge component, it shows you View state
Performance Best Practices

09 May 2017

Wim van den Brink

I think that at the start it is empty, when doc build is ready then the code assigns a value to it, when you look it is filled because you look at the finished document. (hmmm .. not sure if this is completely explanatory enough of the process;-)) Probably this javascript code is generated dynamically when the page is processed by OutSystems

10 May 2017

Bruno Gonçalves

I'm using "View page source" and not "Inspect element".

"View page source" won't reflect the changes made dynamically through jquery.

10 May 2017

Justin James

MVP

Wim -

I see this all the time. Queries that return a lot of fields, then put them into a ListRecords or TableRecords with widgets bound to those fields will do it.

The problem is almost always caused by poor UI design! If you look that the screens which have the issue, you will see that they are showing far too much data to be useful or usable anyways.

J.Ja

10 May 2017

Edgar Ramos

Champion

Hello João,

How do we define a large viewstate and a small viewstate in terms of size?

Edgar

19 Oct 2017

Brian Lorraine

Viewstate is a feature of Web Forms.

Now that Microsoft is switching to .NET Core, they're doing away with web forms and switching to MVC.

In the future, will Viewstate be deprecated in Outsystems code, or will you guys find a way to create a proprietary kind of viewstate?

12 Apr 2018

Community GuidelinesBe kind and respectful, give credit to the original source of content, and search for duplicates before posting.

See the full guidelines