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...

"Mantorok" <no**@tiscali.co.uk> wrote in message
news:dm**********@newsfeed.th.ifl.net...

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

[Mantorok]

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

Thanks
Kev

"Jéjé" <wi******@BBBhotmailAAA.com> wrote in message
news:O1**************@TK2MSFTNGP15.phx.gbl...

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...

"Mantorok" <no**@tiscali.co.uk> wrote in message
news:dm**********@newsfeed.th.ifl.net...

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

[Thomas Skovsende]

Mantorok wrote:

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

[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" <no**@tiscali.co.uk> wrote in message
news:dm**********@newsfeed.th.ifl.net...

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

Thanks
Kev

"Jéjé" <wi******@BBBhotmailAAA.com> wrote in message
news:O1**************@TK2MSFTNGP15.phx.gbl...

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...

"Mantorok" <no**@tiscali.co.uk> wrote in message
news:dm**********@newsfeed.th.ifl.net...

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

[Mantorok]

Ok, that makes sense, thanks very much.

Kev

"Jéjé" <willgart_A_@hotmail_A_.com> wrote in message
news:OH**************@tk2msftngp13.phx.gbl...

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" <no**@tiscali.co.uk> wrote in message
news:dm**********@newsfeed.th.ifl.net...

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

Thanks
Kev

"Jéjé" <wi******@BBBhotmailAAA.com> wrote in message
news:O1**************@TK2MSFTNGP15.phx.gbl...

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...

"Mantorok" <no**@tiscali.co.uk> wrote in message
news:dm**********@newsfeed.th.ifl.net...
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

[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" <t___hsk@net___peo--ple.d-k> wrote in message
news:%2***************@TK2MSFTNGP15.phx.gbl...

Mantorok wrote:

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

[Thomas Skovsende]

gerry wrote:

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