HUGE Viewstate

[Mantorok]

It's not unusual (to be lo....cough) for me to have VIEWSTATE ranging from 1
full page to several pages.....

This seems in-efficient - any ideas how to reduce the thing?

Thanks
Kev

 

[Jéjé]

deactivate the enableviewstate option for the controls where you don't have
to store the state.
for example, a menu, a simple list without any sort/select option authorized
(no need to keep information during a postback). deactivating the viewstate
for these controls reduce the size of the page.

Lookat the http://localhost/folder/trace.axd file to identify which controls
produce your viewstate.

if you use .Net Framework 2.0, deactivating the viewstate for a grid keep
the sort/select commands, while in 1.1 the entire state for the grid must be
saved in the viewstate. (same thing for most of the controls in the v2.0)

There is more options, likestoring the viewstate on the server side,
applying some code to store only the requiered information in the state (but
you have to repopulate your controls) etc...

 

[Thomas Skovsende]

It's not unusual (to be lo....cough) for me to have VIEWSTATE ranging from 1
full page to several pages.....

This seems in-efficient - any ideas how to reduce the thing?

Jéjé came with a good suggestion...

Another one: if you REALLY need the viewstate, google a bit on "flesk
viewstate", which saves viewstate on the server and only sends an id to
the client.

And why this isnt possible to do without 3rd party libs is beyond me

Best regards,
Thomas Skovsende

 

[Mantorok]

Thanks for the advice, do you think a large viewstate is a particularly bad
idea?

Thanks
Kev

 

[Jéjé]

it could be good for intranet usage and for complex form with edition
capability.
So for pages which are less used then navigation pages which are accessed by
more users more frequently.

remember that a large viewstate impact the bandwidth, and if there is a
postback, the viewstate is sent back to the server, so again an impact on
the network.

In the past I have created a complex form with a lot of controls / sub
controls etc.. designed to configure a chart online (the user can change the
colors, axis, values, etc etc...)
This form was really big with a big viewstate, but the user go to this page
only 1 time a month.
In another side, the page which render the chart is really small with a
small viewstate because the page is accessed every day.

 

[Mantorok]

Ok, that makes sense, thanks very much.

Kev

it could be good for intranet usage and for complex form with edition
capability.
So for pages which are less used then navigation pages which are accessed
by more users more frequently.

remember that a large viewstate impact the bandwidth, and if there is a
postback, the viewstate is sent back to the server, so again an impact on
the network.

In the past I have created a complex form with a lot of controls / sub
controls etc.. designed to configure a chart online (the user can change
the colors, axis, values, etc etc...)
This form was really big with a big viewstate, but the user go to this
page only 1 time a month.
In another side, the page which render the chart is really small with a
small viewstate because the page is accessed every day.

 

[gerry]

No 3rd party libs required.
Look into the SavePageStateToPersistanceMedium &
LoadPageStateFromPersistanceMedium Page methods.
These allow full server side viewstate persistance with as little as 2 lines
of code - 1 line of code in each method.
Gerry

 

[Thomas Skovsende]

No 3rd party libs required.
Look into the SavePageStateToPersistanceMedium &
LoadPageStateFromPersistanceMedium Page methods.
These allow full server side viewstate persistance with as little as 2 lines
of code - 1 line of code in each method.

Well - kindof!

I have to write a PageStatePersister class.

What i wanted from MS was something easily configurable from web.config.

Thomas Skovsende