473,320 Members | 2,027 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,320 software developers and data experts.

Easy way to store page state for later requests.

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.

Feb 23 '06 #1
7 2082
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


"Shadow Lynx" wrote:
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.

Feb 23 '06 #2
Would a Server.Transfer work for you as opposed to Response.Redirect?

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

Feb 23 '06 #3
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?

Feb 23 '06 #4
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

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


"Shadow Lynx" wrote:
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?

Feb 23 '06 #5
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.

Feb 24 '06 #6
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" wrote:
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.

Feb 24 '06 #7
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?

Feb 24 '06 #8

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

13
by: Mimi | last post by:
Hello, I am having trouble using the session vars in PHP 4.3.9 OS: Win XP Prof Web Server IIS (is local and there are no links to other servers from the web pages I work on) Browser: IE 6.0 ...
0
by: Santa | last post by:
I am using Fritz Onion's "Asynchronous Pages" approach as mentioned in the article http://msdn.microsoft.com/msdnmag/issues/03/06/Threading/default.aspx to increase the performance of my ASPX...
2
by: John Lau | last post by:
Hi, Is there documentation that talks about the page lifecycle, the lifecycle of controls on the page, and the rendering of inline code, in a single document? Thanks, John
0
by: Santa | last post by:
I am using Fritz Onion's "Asynchronous Pages" approach as mentioned in the article http://msdn.microsoft.com/msdnmag/issues/03/06/Threading/default.aspx to increase the performance of my ASPX...
2
by: steventhrasher42 | last post by:
I very likely may be missing something here, but what stops a user from holding down the F5 key in their browser and generating hundreds of requests to IIS and thus tying up server resources? If...
3
by: Hans Merkl | last post by:
Hi, I am helping to build a web app that's pretty much a wrapper around a web service. The question now is how to store the handle of the web service object between requests. My client is using...
2
by: Max | last post by:
Hi, I am helping to build a web app that's pretty much a wrapper around a web service. The question now is how to store the handle of the web service object between requests. My client is using...
3
by: =?Utf-8?B?VG9ueSBTZXI=?= | last post by:
Come across an issue with IIS process HTTP request one by one, not simultaneously. I have a page that takes a long time to process. When the page is accessed by 2 seperate browser, both request...
70
mideastgirl
by: mideastgirl | last post by:
I have recently been working on a website for an honors association, and have a lot of difficulty but have found help from those on this site. I would like to see if I can get some more help on a...
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
0
by: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
0
by: ArrayDB | last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...
1
by: CloudSolutions | last post by:
Introduction: For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
1
by: Defcon1945 | last post by:
I'm trying to learn Python using Pycharm but import shutil doesn't work
1
by: Shællîpôpï 09 | last post by:
If u are using a keypad phone, how do u turn on JavaScript, to access features like WhatsApp, Facebook, Instagram....
0
by: Faith0G | last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...
0
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome former...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.