«

My application is a simple create/update/delete system, with user
authentication. Everything is working well, except session timeouts are
creating user-experience nightmares.

The standard workflow of my application is as follows:

Login -> View Items -> Edit Item -> Save Item

The following should be noted about each step:
1) Login
The login is a customized version of the FormsAuthentication. It
accesses a database to retrieve user information, and uses
FormsAuthentication.SetAuthCookie/Server.Transfer instead of
FormsAuthentication.RedirectFromLoginPage.
2) View Items
A list of items is retrieved from a database and displayed in a DataList
control.
3) Edit Item
The user clicks on an edit button in the DataList control from step (2),
and is taken to a separate form to edit the information (in-line editing is
not being used).
4) The user clicks a save button, which persists the data to the database
and takes the user back to the View Items page.

As I said, everything is working. The problem I am having is when the user
takes a long time editing the item and his session times out. In such a case
the flow is as follows:

Login -> View Items -> Edit Item -> Click Save -> Login -> Edit Item

This is all well and good, except that upon return to the Edit Item page,
the form values the user has entered are no longer there, so the user must
re-enter the data. Ideally the flow should be:

Login -> View Items -> Edit Item -> Click Save -> Login -> Persist Data to
DB -> View Items

assuming validation passes, otherwise

Login -> View Items -> Edit Item -> Click Save -> Login -> Edit Item

with the form filled out and any viewstate-dependant controls rehydrated.

Any ideas as to how I can accomplish this?

Thanks,
--kaburke

"kaburke" <> wrote in
news:kTsMe.223841$on1.47537@clgrps13:

> This is all well and good, except that upon return to the Edit Item
> page, the form values the user has entered are no longer there, so the
> user must re-enter the data. Ideally the flow should be:
>
> Login -> View Items -> Edit Item -> Click Save -> Login -> Persist
> Data to DB -> View Items
>
> assuming validation passes, otherwise
>
> Login -> View Items -> Edit Item -> Click Save -> Login -> Edit Item
>
> with the form filled out and any viewstate-dependant controls
> rehydrated.
>
> Any ideas as to how I can accomplish this?

I don't think you can easily persist the data on a session timeout.

I would just raise the timeout value to >20 minutes or add some custom
javascript to keep the page alive.

--
Lucas Tam ()
Please delete "REMOVE" from the e-mail address when replying.
http://members.ebay.com/aboutme/coolspot18/

Persisting the filled values themselves doesn't seem to be too difficult.
Currently, when a user is redirected to the login page (because his session
has timed out), I iterate through all of the Form and Querystring parameters
and print out a hidden field for each one. Upon submission of the login
form, the user is sent back to the page of origin (using Server.Transfer),
whereupon the OnInit of my Page class (it is actually the OnInit of a base
class from which all of my pages inherit) loops through the submitted hidden
fields and rehydrates any relevant controls in the Page.

The problem I am now trying to overcome is persistance of the ViewState
information. For example, the form contains a DataList whose enableViewState
property is set to true - when the user is sent back to the form, however,
the DataList is not repopulated. Any ideas as to how I can accomplish this?

Thanks,
--kaburke

"Lucas Tam" <> wrote in message
news:Xns96B4CD8273F92nntprogerscom@127.0.0.1...
> "kaburke" <> wrote in
> news:kTsMe.223841$on1.47537@clgrps13:
>
>> This is all well and good, except that upon return to the Edit Item
>> page, the form values the user has entered are no longer there, so the
>> user must re-enter the data. Ideally the flow should be:
>>
>> Login -> View Items -> Edit Item -> Click Save -> Login -> Persist
>> Data to DB -> View Items
>>
>> assuming validation passes, otherwise
>>
>> Login -> View Items -> Edit Item -> Click Save -> Login -> Edit Item
>>
>> with the form filled out and any viewstate-dependant controls
>> rehydrated.
>>
>> Any ideas as to how I can accomplish this?
>
> I don't think you can easily persist the data on a session timeout.
>
> I would just raise the timeout value to >20 minutes or add some custom
> javascript to keep the page alive.
>
> --
> Lucas Tam ()
> Please delete "REMOVE" from the e-mail address when replying.
> http://members.ebay.com/aboutme/coolspot18/

Coming back from the login page, you'll need to give yourself enough
information to pull the page context out of temporary storage, right?
Since you've already got a branch set up to put the fields back in
place, why not repopulate and rebind at the same time? Unless your
DataList is particularly expensive to rebuild, I don't see much value
in trying to freeze & thaw the ViewState.

Jason Kester
Expat Software Consulting Services
http://www.expatsoftware.com/

With a DataList that may be the best option, but with other controls such a
technique may be irritating and cumbersome. On the form, for example I have
labels whose values change to reflect UI state (e.g., whether the record
being represented is "dirty"). For example (using the "dirty" scenario), the
Page_Load sets the label's text to "Unmodified," but when the contents of
any control on the form are changed, the label is changed to "Modified." In
such a case it would be far more convenient to merely "thaw," as you say,
the ViewState, rather than have to analyse the record for changes upon
redirection from the login page. This is particularly true as I would like
to implement a generic means of maintaining state through a Session Timeout
(i.e., on this page I have a "dirty" label, but elsewhere what needs to be
preserved will be entirely different, and I don't want to have to implement
custom rehydration code for every page).

Thanks,
--kaburke

"jasonkester" <> wrote in message
news: ups.com...
> Coming back from the login page, you'll need to give yourself enough
> information to pull the page context out of temporary storage, right?
> Since you've already got a branch set up to put the fields back in
> place, why not repopulate and rebind at the same time? Unless your
> DataList is particularly expensive to rebuild, I don't see much value
> in trying to freeze & thaw the ViewState.
>
> Jason Kester
> Expat Software Consulting Services
> http://www.expatsoftware.com/
>

I found the solution to my problem here:

http://www.codeproject.com/aspnet/Pe...tStatePage.asp

My situation was not identical to the scenario outlined in the article, but
the methods described where easily translated.

Thanks,
--kaburke

"kaburke" <> wrote in message
news:kTsMe.223841$on1.47537@clgrps13...
> My application is a simple create/update/delete system, with user
> authentication. Everything is working well, except session timeouts are
> creating user-experience nightmares.
>
> The standard workflow of my application is as follows:
>
> Login -> View Items -> Edit Item -> Save Item
>
> The following should be noted about each step:
> 1) Login
> The login is a customized version of the FormsAuthentication. It
> accesses a database to retrieve user information, and uses
> FormsAuthentication.SetAuthCookie/Server.Transfer instead of
> FormsAuthentication.RedirectFromLoginPage.
> 2) View Items
> A list of items is retrieved from a database and displayed in a
> DataList control.
> 3) Edit Item
> The user clicks on an edit button in the DataList control from step
> (2), and is taken to a separate form to edit the information (in-line
> editing is not being used).
> 4) The user clicks a save button, which persists the data to the database
> and takes the user back to the View Items page.
>
> As I said, everything is working. The problem I am having is when the user
> takes a long time editing the item and his session times out. In such a
> case the flow is as follows:
>
> Login -> View Items -> Edit Item -> Click Save -> Login -> Edit Item
>
> This is all well and good, except that upon return to the Edit Item page,
> the form values the user has entered are no longer there, so the user must
> re-enter the data. Ideally the flow should be:
>
> Login -> View Items -> Edit Item -> Click Save -> Login -> Persist Data to
> DB -> View Items
>
> assuming validation passes, otherwise
>
> Login -> View Items -> Edit Item -> Click Save -> Login -> Edit Item
>
> with the form filled out and any viewstate-dependant controls rehydrated.
>
> Any ideas as to how I can accomplish this?
>
> Thanks,
> --kaburke
>