View state in OutSystems Applications

View state in OutSystems Applications

  
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:
http://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
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
good explanation, but there are some pictures missing.

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

cr