The size will become prohibitive if you site has a lot of hits, and you have
to decide at what point you want to remove the server side storage of the
viewstate. IOW how many "backs" do you want to allow your user to do?
And then you have to decide how you want to handle no viewstate recorded for
the page. (you have purged the record from memory).
The easiest (and arguably lamest way), is to save the viewstate with the
hidden field GUID suggested by Bruce. Then if the GUID doesn't match the
GUID of the object saved into Session, you could display and error message
for the user telling them, they can't hit the back button, please use the
navigation provided on the page.
I am not sure what type of information you are saving in viewstate, but on a
page I was serializing a DataTable to the page, it become prohibitive in
viewstate after 20 records or so (noticeably slower). I just saved the
query used to build the DataTable into viewstate, much smaller. I am
placing more load on my SQL, but Sql is better at running queries than the
framework deserializing 30K of viewstate.
So you might be able to save the instructions for creating the large amount
of data and you could bypass the whole issue entirely.
bill
"Ollie" <ol**********@h otmail.com> wrote in message
news:eu******** ******@tk2msftn gp13.phx.gbl...
nice idea I like it are there any drawbacks to this approach of handling
viewstate?
Ollie Riches
"bruce barker" <no***********@ safeco.com> wrote in message
news:Of******** ******@TK2MSFTN GP09.phx.gbl... you store a guid on the page in a hidden field, so you can find the matching viewstate. if the viewstate can not be found (deleted from cache)
redirect to the page.
-- bruce (sqlwork.com)
"Ollie" <why do they need this!!!!> wrote in message
news:e0******** **********@TK2M SFTNGP09.phx.gb l...
| surely storing the view state on the server could lead to different
| behaviour when the user makes use of the 'back' and forward' buttons
on a | browser?
|
| Ollie Riches
|
| "William F. Robertson, Jr." <theman_at_fdrs ucks.com> wrote in message
| news:O0******** ********@TK2MSF TNGP12.phx.gbl. ..
| > There are probably several ways to tackle this but here is how I
have done
| > it in the past.
| >
| > You will need to override two methods for your control.
| > protected override void LoadViewState(o bject savedState);
| > protected override object SaveViewState()
| >
| > SaveViewState returns the object that should be placed into
viewstate. So
| > you intercept it and store it into session
| >
| > protected override object SaveViewState()
| > {
| > //this will load the viewstate as normal
| > object o = base.SaveViewSt ate();
| >
| > //store it into session
| > System.Web.Http Context.Current .Session[this.ID] = o;
| >
| > //i think you need to return something (not null) in order for
| > LoadViewState
| > return new object();
| > }
| >
| > protected override void LoadViewState( object savedState )
| > {
| > //load the savedState from Session
| > savedState = System.Web.Http Context.Current .Session[this.ID];
| >
| > //call base constructor
| > base.LoadViewSt ate( savedState );
| > }
| >
| > HTH,
| >
| > bill
| >
| >
| > "clsmith66" <cl*******@disc ussions.microso ft.com> wrote in message
| > news:47******** *************** ***********@mic rosoft.com...
| >> Is it possible to store the same information about a control that
would | >> be
| >> saved in the ViewState in a Session state? I have a page with
three | > treeview
| >> controls and if I enable the view state for the controls I get huge
| >> delays
| > on
| >> postbacks, but if I disable the viewstate I lose all my
information. Any
| >> sugesstions?
| >
| >
|
|
