Kill ViewState !!!

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Hi
Like me many people are suffering from the ' overhead ' of HUGE ViewState (specially large Combos, DataGrid, Etc.

I don't understand why is ViewState (passed to client in form of that 'hidden' field) need @ all ???

What i've seen is that value of 'EVERYTHING' (mean each control rendered - including dynamically rendered datagrid and other databound controls) can be fetched from 'Request.Form("ID")

Then for what reason did MS implement ViewState
(may be to test Network ?

Any comments ??
Hmnt
 
You can only fetch from Request.Form what is posted with the form. For
example, DropDownList (HTML SELECT element) posts only its selected value
but not *all* the items. Therefore you'd need to roundtrip the other,
non-selected values, via ViewState (or repopulate the control). DataGrid
definitely does not post itself, if it contains controls that post, they do,
but not DataGrid itself. Automatically posting controls are only those basic
HTML elements that post normally with the form.

ViewState was developed to have state management for controls which do not
keep their state over postback automatically. I am sure it wasn't developed
just for fun. ;-)

About dealing with the large ViewState:

You can turn it completely to the server so that it won't affect the page
size.

Alternatives:
a) to session (see: http://aspalliance.com/135)
b) to other custom store like database or file
c) You could have a ViewState Optimizer
d) You can also impact yourself, how your controls generate ViewState. Turn
it off for those, that do not need it.

Here's a a few articles about DataGrid's ViewState optimizing:
http://authors.aspalliance.com/jimross/Articles/DatagridDiet.aspx
http://authors.aspalliance.com/jimross/Articles/DatagridDietPartTwo.aspx

--
Teemu Keiski
MCP, Microsoft MVP (ASP.NET), AspInsiders member
ASP.NET Forum Moderator, AspAlliance Columnist
http://blogs.aspadvice.com/joteke




Hi,
Like me many people are suffering from the ' overhead ' of HUGE ViewState
(specially large Combos, DataGrid, Etc.)

I don't understand why is ViewState (passed to client in form of that
'hidden' field) need @ all ???

What i've seen is that value of 'EVERYTHING' (mean each control rendered -
including dynamically rendered datagrid and other databound controls) can be
fetched from 'Request.Form("ID")'

Then for what reason did MS implement ViewState
(may be to test Network ?)

Any comments ???
Hmnt
 
To second and add to Teemu's response, I remember the code I used to have
to write to restore position in SELECT lists in ASP.
It was not fun.
Nor was doing what had to be done for radio buttons and checkboxes.
Definitely a fun-free zone it was.
And *sooooooooo* monotonous.
 
Hi

Thx fo reply ... but what i don understand is that even for those 'Some' control(s) which can be retrived from

'Request.Form["ID"] ' - why is the viewState used AT-ALL. Even EACH Label control on page has its own ViewState !!

If sysstem has the information about all those fields that can be fetched from 'Request.Form["ID"] ' then why should it by-default handle it ? - that is eliminate its ViewState (which can be easily restored upon Postback !!

So what do u think
 
Hi,

Label for example is a SPAN HTML Element at client-side and it can't keep
its state over postback, unless this state is stored to somewhere (or as
stated before, repopulated). So it uses ViewState, from where value of Text
property is fetched on postback. Of course, there's always the chance to
disable ViewState and take the classic route and populate the control
manually on every request.

But yes, the ViewState behaviour is more interesting with the controls that
do post along with the form. Take a TextBox for example. It in fact does not
need ViewState at all to keep its state, but it uses ViewState to raise
TextChanged event, that is, to detect if its state changed during a
postback. I've discussed how ViewState works in TextBox in a blog post:
http://blogs.aspadvice.com/joteke/archive/2004/03/15/767.aspx

This behaviour concerns pretty much the controls implementing
IPostBackDataHandler interface, the built-in controls which are posting HTML
elements at client-side, usually implement this interface. They check in
IPostBackDataHandler.LoadPostData implementation that what was posted, and
update their state accordingly. So their state goes mainly via posting, not
via ViewState, though there are exceptions, like DropDownList, which posts
the selection but not all items (DDL raises SelectedIndexChanged event based
on difference in selected item between previous and current
request/postback). So common behavior for these controls is, that they are
more independent what comes to ViewState, but they then utilize it bit
differently to aim for better usability and to help in development
scenarios.

--
Teemu Keiski
MCP, Microsoft MVP (ASP.NET), AspInsiders member
ASP.NET Forum Moderator, AspAlliance Columnist
http://blogs.aspadvice.com/joteke

Hi,

Thx fo reply ... but what i don understand is that even for those 'Some'
control(s) which can be retrived from

'Request.Form["ID"] ' - why is the viewState used AT-ALL. Even EACH Label
control on page has its own ViewState !!!

If sysstem has the information about all those fields that can be fetched
from 'Request.Form["ID"] ' then why should it by-default handle it ? - that
is eliminate its ViewState (which can be easily restored upon Postback !!!

So what do u think ?
 
Back
Top