Re: User control remember state across pages without session
- From: "KMA" <kma@xxxxxxxx>
- Date: Mon, 24 Oct 2005 08:48:47 +0200
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.
"McGeeky" <anon@xxxxxxxx> wrote in message
news:OIdRY6y1FHA.3568@xxxxxxxxxxxxxxxxxxxxxxx
> 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
>
>
> "Kevin Spencer" <kevin@xxxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
> news:e8eB4ml1FHA.2212@xxxxxxxxxxxxxxxxxxxxxxx
> > 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.
> >
> > --
> > HTH,
> >
> > Kevin Spencer
> > Microsoft MVP
> > .Net Developer
> > Ambiguity has a certain quality to it.
> >
> > "McGeeky" <anon@xxxxxxxx> wrote in message
> > news:enTSVBl1FHA.460@xxxxxxxxxxxxxxxxxxxxxxx
> > >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
> > >
> > > --
> > > McGeeky
> > > http://mcgeeky.blogspot.com
> > >
> > >
> > > "McGeeky" <anon@xxxxxxxx> wrote in message
> > > news:O3dmK%23k1FHA.3756@xxxxxxxxxxxxxxxxxxxxxxx
> > >> 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.
> > >>
> > >> --
> > >> McGeeky
> > >> http://mcgeeky.blogspot.com
> > >>
> > >>
> > >> "KMA" <kma@xxxxxxxx> wrote in message
> > >> news:djauun$ikg$1@xxxxxxxxxxxxxxxxxxxx
> > >>> 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?
> > >>>
> > >>>
> > >>> "McGeeky" <anon@xxxxxxxx> wrote in message
> > >>> news:OzkY91k1FHA.1256@xxxxxxxxxxxxxxxxxxxxxxx
> > >>>> No. It could be different for each client
> > >>>>
> > >>>> --
> > >>>> McGeeky
> > >>>> http://mcgeeky.blogspot.com
> > >>>>
> > >>>>
> > >>>> "KMA" <kma@xxxxxxxx> wrote in message
> > >>> news:djatq6$igr$1@xxxxxxxxxxxxxxxxxxxx
> > >>>> > should the state of the UC be the same for all clients?
> > >>>> >
> > >>>> > "McGeeky" <anon@xxxxxxxx> wrote in message
> > >>>> > news:uhVVbRk1FHA.3564@xxxxxxxxxxxxxxxxxxxxxxx
> > >>>> >> 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!
> > >>>> >>
> > >>>> >> --
> > >>>> >> McGeeky
> > >>>> >> http://mcgeeky.blogspot.com
> > >>>> >>
> > >>>> >>
> > >>>> >>
> > >>>> >
> > >>>> >
> > >>>>
> > >>>>
> > >>>
> > >>>
> > >>
> > >>
> > >
> > >
> >
> >
>
>
.
- Follow-Ups:
- References:
- User control remember state across pages without session
- From: McGeeky
- Re: User control remember state across pages without session
- From: KMA
- Re: User control remember state across pages without session
- From: McGeeky
- Re: User control remember state across pages without session
- From: KMA
- Re: User control remember state across pages without session
- From: McGeeky
- User control remember state across pages without session
- Prev by Date: Re: Application Design Question
- Next by Date: Re: How to handle null values in DataBinder.Eval()
- Previous by thread: Re: User control remember state across pages without session
- Next by thread: Re: User control remember state across pages without session
- Index(es):
Relevant Pages
|
