This article applies to all versions up to Gaia Glory 3.0 SP1. Disabled ViewState is scheduled to be supported in future versions of Gaia.
Improve Article
// Improve 1 : Add links to other interessting ViewState articles.
// Improve 2 : Show example of Composition pattern and best practice of control instantiation
// Improve 3 : Revise writing.
Gaia inherits from the ASP.NET WebControl model. This means that Gaia also takes advantage of the ViewState from ASP.NET. Some of you might have read "bad things" about the ViewState other places and about how it "bloats your page" and so on. The ViewState is a really brilliant way of keeping "state" across postbacks (and callbacks) and its reputation is far worse than what it deserves. A lot of the "fear of the ViewState" is not justified and has its foundation in wrong usage of it or a lack of understanding in regards to it. But like all abstractions it leaks. This means that if you don't know anything about ViewState than chances are that you will not use it optimally which in turn will make your page suffer.
I am not going to go into a deep explanation about how the ViewState works since that is far beyond the scope of this article, but I will try to give you some few hints in regards to using it optimally in addition to explaining how Gaia's relationship to the ViewState is.
In Gaia you cannot turn off ViewState. At least not for the Gaia Controls on your page. This is because at the very heart of Gaia there is a comparison of "values already set on the client" and "values updated during the current Ajax request" to find out the delta and know what to update back to the client for specific widgets. And if you turn OFF ViewState then Gaia has no mechanism to know which values and properties for specific widgets have been updated during the current Ajax Request and therefore will not be able to correctly update your UI. This might be seen as a "backdraft" of Gaia but if you use the ViewState on your page correctly, then this will not matter much for you in fact. To keep the ViewState VERY small is in fact very easy if you follow some few "best practices" in regards to it.
Edit"Best Practices" in regards to ViewState usage in Gaia Ajax Widgets
For "static" controls (meaning controls declared in your .ASPX page) the ViewState carries VERY little overhead, if any at all. Though for Dynamically Created controls the situation is a bit different. Very often when you create Dynamic Controls this is a three phase run;
- Instantiate the Controls
- Set its values
- Add it either directly or in-directly to the Page object
IF you follow the EXACT same steps in the given sequence as the above list, then your ViewState object will be SIGNIFICANTLY reduced in size! This is also true for ALL WebControls and not only Gaia Ajax Widgets.
The reason is that when your dynamically created Controls are being added to the page object then its complete lifecycle will execute which means that among other things the ViewState "IsDirty" flag will be set to TRUE. When the ViewState IsDirty flag is set to true, then all properties you modify afterwards will have its values stored in the ViewState object. If you however set those properties BEFORE adding the Control to the Page object then the ViewState will not be dirty for those properties and values.
By "adding to the page" we mean adding the control to the Control collection of any control which is "anchored" to the page object. This means that you can create "Control Hierarchies" without "adding the control to the page" but make sure your "top most" control in these hierarchies is NOT added to the page before all OTHER controls have been added to it and had their properties modified to whatever value they're supposed to have.
So here is the rule of thumb; Always add the control to the page or the anchored parent control as the LAST step you do when using Dynamically Created Controls.
If you remember the above sentence and follow up on it, you will have a most pleasent experience with the ViewState in your applications.