HUGE Viewstate

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

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" <> wrote in message
news:dmk2bk$33u$...
> 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é

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

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

Thanks
Kev

"Jéjé" <> wrote in message
news:...
> 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" <> wrote in message
> news:dmk2bk$33u$...
>> 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

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" <> wrote in message
news:dmk8fa$6qm$...
> Thanks for the advice, do you think a large viewstate is a particularly
> bad idea?
>
> Thanks
> Kev
>
> "Jéjé" <> wrote in message
> news:...
>> 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" <> wrote in message
>> news:dmk2bk$33u$...
>>> 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é

Ok, that makes sense, thanks very much.

Kev

"Jéjé" <willgart_A_@hotmail_A_.com> wrote in message
news:...
> 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" <> wrote in message
> news:dmk8fa$6qm$...
>> Thanks for the advice, do you think a large viewstate is a particularly
>> bad idea?
>>
>> Thanks
>> Kev
>>
>> "Jéjé" <> wrote in message
>> news:...
>>> 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" <> wrote in message
>>> news:dmk2bk$33u$...
>>>> 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

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

gerry

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

Thomas Skovsende