When to Disable View State?

Hi Jared,

I've disabled view state on nearly every web part -- typically by disabling it for entire zones. I work on news sites so most of our material is articles and listings, which don't need the view state. Once it's disabled, the reduction in bloat is remarkable -- just take a look at the page source before and after disabling the view state!

The one area you have to be careful is with any web part that relies on the user session in some way, such as the logon web parts. Also any controls on a page may need view state. There's a detailed article about view state on MSDN.

A while back, someone suggested that view state be disabled by default. Even better would be if the web parts that needed it on, had view state enable, and the rest would have it disabled.

@Jared, the article you mentioned is a great reference. Any webpart with form fields, buttons or requires a postback, you should leave view state enabled.

For your specific questions, yes leave the viewstate enabled for searching because it requires a postback to retrieve data and for paging. When viewstate is disabled on controls which require it, they won't function as you'd expect and you'll notice it immediately and/or receive errors. If viewstate is disabled in the parent container, it will be disabled for the child containers so your example of a widget that requires it in an editable text webpart will not work. Generally enabling/disabling viewstate depends on the site and requirements. In Emma's case, it sounds like there isn't a lot of data entry so it makes sense to disable it on most webparts. In some of the sites I've worked on, its nearly impossible to disable any of it.

To add to what Emma stated, you can disable those system settings by default by simply going to the webpart and clicking on the System Properties tab and checking the DisableViewState property.

@Jared, unfortunately, your own answers are not entirely correct.

RE: Bizforms
if you have conditions set on visibility and enabled which require a field to post back, the form will not work. If you allow the form to be edited after submission, the form will not work as expected. If you have cascading dropdowns or any dependencies on other fields on that form, it will not work without viewstate enabled.

RE widgets in editable text
I've created several widgets that allow for data entry and every one of them need viewstate enabled. Although you can't think of a reason, there are some out there which will need them. Take the Reporting widget for example, if you place a report on a page and it has parameters associated with it, those cause a postback and are required for the report to do what it needs. If someone can do it, they will.

RE Finding information about viewstate
There are many people who care about it, you just have to know where to look. Since viewstate is not a Kentico "thing" it's an asp.net "thing", I'd suggest checking out the MSDN documentation for more information on what viewstate is and how it works. Kentico is a regular asp.net website.