Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsFree MagazinesWhite PapersSubmit Content
Discussion GroupsASP.NETWindows FormsLanguages.NET FrameworkVisual Studio.NET
Articles.NET FrameworkASP.NETToolsWindows Forms
.NET DirectoryOpen Source ProjectsUser GroupsWeb Resources
Related Topics
Visual Basic 6SQL ServerMS AccessOther DB ProductsMS Server ProductsMore Topics ...

.NET Forum / ASP.NET / General / October 2005

Tip: Looking for answers? Try searching our database.

User control remember state across pages without session

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
McGeeky - 21 Oct 2005 14:35 GMT
Is there a way to get a user control to remember its state across pages? I
have a standard page layout I use with a header and footer as user controls.
Each page uses the same layout by means of copy paste (I hear this will
improve in ASP.Net 2 via master pages).

When I navigate from one page to the next the header and footer user
controls lose their state because they are effectively different instances
of the user control.

Is there any way I can make the state of the user control exist between
pages?

Preferably without the use of hand coding the storing of data in the session
or passing parameters to the user control on each page that includes it. Is
there a way of making the user control state "global"?

Thanks!

Signature

McGeeky
http://mcgeeky.blogspot.com

KMA - 21 Oct 2005 15:26 GMT
should the state of the UC be the same for all clients?

> Is there a way to get a user control to remember its state across pages? I
> have a standard page layout I use with a header and footer as user controls.
[quoted text clipped - 17 lines]
> McGeeky
> http://mcgeeky.blogspot.com
McGeeky - 21 Oct 2005 15:41 GMT
No. It could be different for each client

Signature

McGeeky
http://mcgeeky.blogspot.com

> should the state of the UC be the same for all clients?
>
[quoted text clipped - 24 lines]
>> McGeeky
>> http://mcgeeky.blogspot.com
KMA - 21 Oct 2005 15:45 GMT
Well, the control state isn't "global", is it. It depends on the client, or
session of that client to be precise. What's your objection to using session
state to store the state of the session?

> No. It could be different for each client
>
[quoted text clipped - 30 lines]
> >> McGeeky
> >> http://mcgeeky.blogspot.com
McGeeky - 21 Oct 2005 15:55 GMT
My preference is that all state should be passed to each page as URL
parameters to make testing and problem determination much easier.

I thought that there would be some way for a user control's viewstate to
persist between pages without having to use the session.

Signature

McGeeky
http://mcgeeky.blogspot.com

> Well, the control state isn't "global", is it. It depends on the client,
> or
[quoted text clipped - 42 lines]
>> >> McGeeky
>> >> http://mcgeeky.blogspot.com
McGeeky - 21 Oct 2005 16:01 GMT
I should clarify:

I thought that there would be some **automatic** way for a user control's
viewstate to persist between pages without having to use the session.

Thanks

Signature

McGeeky
http://mcgeeky.blogspot.com

> My preference is that all state should be passed to each page as URL
> parameters to make testing and problem determination much easier.
[quoted text clipped - 48 lines]
>>> >> McGeeky
>>> >> http://mcgeeky.blogspot.com
Kevin Spencer - 21 Oct 2005 17:08 GMT
HTTP is stateless. An HTTP Request is received by the web server. It hands
it off the the ASP.Net application. The application identifies the handler
for that Request (a Page class). The Page class is instantiated and handles
the Request. It sends a Response to the client. Then it goes out of scope,
off into NothingLand. The next Request comes for a Page. The same thing
happens again.

Now, as HTTP is stateless, ASP.Net includes some tricks for persisting state
across Page Requests. One is the PostBack. When the PostBack is received, it
contains the values in the Page, which are used to re-build the Page class
on the server in the state it was on the client. Without it, the Page form
would be completely empty of values, as HTTP is stateless. Another is
ViewState. ViewState uses a hidden form field which is inserted into the
Page when the Response is sent to the browser. It contains the current state
of all the form elements in the Page. When the Page Posts back, the
ViewState is read, and the new Page instance is re-populated with the saved
state of the Page coming from the POST Request.

Note that this enables ONE PAGE class to remember the state IT was in prior
to a PostBack. So, how do you persist data across multiple pages? After all,
HTTP IS STATELESS (I'm going to keep repeating this so that you will get it
drummed into your head - it is VERY important). Well, HTML has a mechanism
for remembering a few things. It's called Cookies. So, when the first
Request for a Page comes from any client, the Session Collection has a new
member added to it, with a unique ID, a Guid, that identifies the client
that sent the Request. This Guid is sent back to the client in the
Response.Cookies collection, as a Session Cookie (it is not saved on the
client, except during the current Session). Every time the browser makes a
Request, it sends its Cookies in the Request header. The server reads the
Session Cookie, and uses the Session object for that client during that
Request/Response.

So, are there any other ways to save the state of a User Control across
multiple page requests? Sure, but they all involve one thing: The client
must be uniquely identified on the server, so that the Page handling the
Request, which remembers nothing about any previous Requests (because HTTP
IS STATELESS), can identify what client data to fetch for that Page. How to
do that? Well, a Cookie comes to mind. You could create a Guid on the
server, and pass it to the client in the Response.Cookies Collection, and
read it every time a new Request comes back. You would have to store both
the Cookie Guid, and the User Control data somewhere. Now, you obviously
don't want to store it in memory, or you would probably use Session. You
could store it in a database, though, for example. Of course, as HTTP IS
STATELESS, and the server has no way to know when the client user has lost
interest and navigated somewhere else, you would have to include some sort
of Timeout process to remove the data from the database after a specified
interval with no Requests.

This is, of course, how Session works. So you don't have to.

Signature

HTH,

Kevin Spencer
Microsoft MVP
.Net Developer
Ambiguity has a certain quality to it.

>I should clarify:
>
[quoted text clipped - 55 lines]
>>>> >> McGeeky
>>>> >> http://mcgeeky.blogspot.com
McGeeky - 22 Oct 2005 18:33 GMT
So, no, a user control cannot maintain state across pages without using the
session.

Its a shame Microsoft don't extend viewstate beyond a single page because it
would be very useful.

--
McGeeky
http://mcgeeky.blogspot.com

> HTTP is stateless. An HTTP Request is received by the web server. It hands
> it off the the ASP.Net application. The application identifies the handler
[quoted text clipped - 121 lines]
> >>>> >> McGeeky
> >>>> >> http://mcgeeky.blogspot.com
KMA - 24 Oct 2005 07:48 GMT
It would eat into bandwidth a bit. And by the time you've specified what
should and shouldn't be included you could have just coded the storage in
Session, which , after all, is the appropriate place.

You should have seen what things were like before Session.

> So, no, a user control cannot maintain state across pages without using the
> session.
[quoted text clipped - 146 lines]
> > >>>> >> McGeeky
> > >>>> >> http://mcgeeky.blogspot.com
McGeeky - 24 Oct 2005 09:36 GMT
I appreciate that the session is a very useful feature. I have worked with
sessions many times before (not in ASP but JSP, from Java land) - but I just
don't like to load them up with data if I can help it at all.

Thanks for your feedback anyway. Its helped to shine some light in the dark
corners of my knowledge of ASP.Net.

Signature

McGeeky
http://mcgeeky.blogspot.com

> It would eat into bandwidth a bit. And by the time you've specified what
> should and shouldn't be included you could have just coded the storage in
[quoted text clipped - 188 lines]
>> > >>>> >> McGeeky
>> > >>>> >> http://mcgeeky.blogspot.com
Bruce Barker - 21 Oct 2005 17:39 GMT
you should use session, but put the code in the header and footer so the
pages need no knowledge of it. this is called encapsulation, a main design
feature of oo languages.

-- bruce (sqlwork.com)

> Is there a way to get a user control to remember its state across pages? I
> have a standard page layout I use with a header and footer as user
[quoted text clipped - 13 lines]
>
> Thanks!

Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.