Easy way to store page state for later requests.

[Shadow Lynx]

I realize that his question has been asked, in many other forms, many
times in this group. Even so, my tired eyes have not yet found a
sufficient answer, so I've decided to "reask" it even though I'm sure
this will offend some of the more seasoned verterans of this board.

The Players:

Consider a simple web form, which I'll call Page A, that has a couple
of controls on it. It's not important what they are, only that they're
static (not dynamically created) controls. Our old friend ViewState
and Request.Form keeps track of the values and settings of these
controls as the page is posted back to itself.

Consider a second web form, which I'll call Page B, that also has a
couple of (different) controls on it.

The Game:

1. After filling out some information on Page A, a button on that page
is clicked which causes a postback and the event handler for the button
calls a Response.Redirect to Page B.
2. After sticking some data in Page B's form fields, a button on that
page is clicked which causes postback and the event handler calls a
Response.Redirect back to Page A.
3. Back on Page A, all of the data entered is gone. Going back to Page
B, all of that data is gone as well.

The Question:

How do you "keep" the data in the form fields of a page when you leave
that page and how do you "restore" it when you return? I know that
HTTP is inherantly stateless and I know it's possible to manually save
each piece of data in the Session, but that is extremely tedious to say
the least.

I want to know of an "easy" way to store all of the form field data (in
the Session would be fine) so that subsequent returns to the page will
show me the original values I put in, and I do NOT want to do any of
this manually. The concept is a ViewState that persists across
different page requests. An acceptable solution would simply "remember
and recall" just the values of the form fields, but the ultimate
solution would also do that for all properties of controls (such as
which are hidden, enabled, etc.)

If there is no elegant solution for this then maybe I'm just barking up
the wrong tree and should ask for it as an ASP.NET 3.x feature.

 

[Guest]

Shadow Lynx,
if it is that important to your business logic scenario, you could certainly
write some sort of class / method that would handle this in a more automated
manner, e.g., before the redirect it would iterate over all the page controls
and store their names and values in a hashtable using a custom class, keyed
by the pagename +controlname or something similar. The Hashtable could then
be stored in Session state.

Otherwise, you can simply store the values in Session or even in Cache with
a unique key that prevents user-collisions.

Hope that helps.
--Peter

--
Co-founder, Eggheadcafe.com developer portal:
http://www.eggheadcafe.com
UnBlog:
http://petesbloggerama.blogspot.com

 

[Darren Kopp]

Would a Server.Transfer work for you as opposed to Response.Redirect?

-Darren Kopp
http://blog.secudocs.com/

 

[Shadow Lynx]

Let me wax lackadaisical and get right to my point.

Why exactly does something simple like saving the ViewState to the
Session (via SavePageStateToPersistenceMedium/Load...) NOT work?

I'm going to oversimply things and make believe that ViewState also
contains all values that normally live in Request.Form. In this little
fantasy, where all things are part of the ViewState, why exactly does
saving the ViewState, navigating to a different page then navigating
back and reloading the ViewState not work (it throws an Invalid
ViewState Exception, not to mention LoadPageStateFromPersistenceMedium
isn't called on the initial page load - only on PostBacks)?

I guess I'm just cranky because there's not an elegant, built-in
solution to handle this situation. Sure, ViewState is there to
maintain state during requests to the same page, but why not for later
requests as well? If the whole ViewState mechanism and other parts of
the existing page building engine handle rebuilding controls along with
setting their values, why can't this be used whenever rather than only
on postback to the same page?

 

[Guest]

Shadow Lynx,
In ASP.NET 2.0, such a mechanism is provided via the PreviousPage property.
ViewState doesn't preserve the values of all form fields on a page to begin
with, only those that have changed - see short article here with some details
and a couple of links to other controls that may be of interest.

http://www.eggheadcafe.com/articles/20060208.asp

Peter

 

[Shadow Lynx]

I know that ViewState doesn't preserve all of the values, which is why
I said that I was "making believe" that the ViewState did so to
simplify the scenario. The PreserveProperty Control on the page you
provided a link to is a great idea but doesn't really accomplish what
I'm looking for, because it requires you to specify each value you want
to preserve. In a way, this is opposite the direction I want to go. I
want to save the State of the entire page, from control properties to
values, and recall it the next time that page is visited, and I have no
interest in specifying individual settings to save. Yes, I know, I'm
lazy.

As for the PreviousPage property in .NET 2.0, could you be more
specific? I looked up Page.PreviousPage and it is basically a
reference back to the calling page, only available when doing a
Server.Transfer or Cross-Page Posting.

In my situation (and what I believe is the situation of many others) I
want to basically maintain page state across different arbitrary page
requests, per session. For example, let's say several pages have
object-specific searches on them and I want each search form to
"remember" what the last search was. A full-page "state-keeper" would
remember the state of everything on a page (without needing to specify
any particular controls) and be able to restore it each time that page
was requested no matter how many other different pages were requested
inbetween. One limitation, I realize, is that normal href links
couldn't be used because then the "state-keeper" wouldn't get a chance
to save the state into the session before the next page is loaded.
Instead, LinkButtons would need to be used instead, with
Response.Redirects in their event handlers.

 

[Guest]

OK.
While I have no particular interest in this "venture", this is one way I
might pursue it:

1) Override the SavePage State.. and LoadPageState..
(fromPersistenceMedium)methods which will allow you to iterate all the
controls on your page and for those that don't particularly get an ViewState
entry, you will create one.
2) use one of the infrastructures that stores this "custom viewstate" object
in either Session, Cache, or even in your favorite database. Make sure that
you figure out a way to do this so that you can choose the page name and
actually reuse this state object on another page (one that's the target of a
server.transfer, for example).
Robert Boedigheimer has such an article, and I did a similar one on our site
that references his work, for testing speed considerations.
Hope that gives you some ideas.

Remember, some of the best inventions come from our inherent laziness as
developers...
Peter

--
Co-founder, Eggheadcafe.com developer portal:
http://www.eggheadcafe.com
UnBlog:
http://petesbloggerama.blogspot.com

 

[Shadow Lynx]

If I iterated through the page's controls, sticking the actual controls
in the Session (for example), would that also save their various
properties and values, allowing me to, when the page is loaded again in
the future, replace the controls on the page with those stored in the
Session? In that case, it might make sense to just have one big fat
Panel that holds everything and can be stuck in the Session (with all
of its children.) Of course, I still have the issue where
LoadPageState... doesn't run the first time the page loads, which is
the one and only time I would need it to run... Would it be possible
to take these actions in another part of the page building cycle?