I said:
I code pages like that as a state machine so that all three (four?)
pages are the same page and I pass back and forth state and event
tokens so that I know where I am. That way if they update the record
and then navigate back to the "update" page, instead of viewing the
same record they're back to the list of records.
Well, I'll show you an example in a second, but first I want to mention
that it's not just the back-button you've got to worry about; there is
also the refresh button, to say nothing of Ctrl-Refresh.
For a good treatment of the whole topic I recommend:
Trap the Browser Refresh by Dino Esposito
"Learn to catch and handle the Refresh trigger so it works the way
you want it to."
From the September 2003 issue of asp.NetPro magazine.
It is available here:
http://www.aspnetpro.com/features/2003/09/asp200309de_f/asp200309de_f.asp
That has no relation to what I'm about to show you, but Mr Esposito's
solution is probably a lot better than mine. I just do mine this way
because I'm an old state machine guy.
Now, going back to the proposed Customers Addresses example, I'm going
to write some simple ASP style code, and it's only going to be
schematic, but I think you will get the idea.
----
Dim myName
myName = Request.ServerVariables("SCRIPT_NAME")
Dim myEvent, myState
If session("state") = "" Then
myState = "ListingAddrs"
session("state") = myState
Else
myState = session("state")
End If
' Events
' AddAddr - User wants to add an address
' DeleteAddr - User has requested a delete
' EditAddr - User wants to modify an address
' InsertAddr - User has requested we save the new address
' UpdateAddr - User wants us to update the edited address
' Cancel - User wants to back out of the current state
' Default - Initialization or an unknown event
' States
' AddingAddr - Displaying blank form for new address
' DeletingAddr - Verifying & performing delete decision
' EditingAddr - Displaying addr update form
' ListingAddrs - Table style display of addresses
----
Now for the meat.
----
myEvent = request("event")
select case myEvent
case "EditAddr"
Call displayEditAddrForm(params)
myState = "EditingAddr"
case "AddAddr"
Call displayAddAddrForm()
myState = "AddingAddr"
case "InsertAddr"
Call insertAddrRecord(params)
Call listAddrs()
myState = "ListingAddrs"
case "DeleteAddr"
Select Case myState
case "EditingAddr"
Call deleteAddrVerify()
myState = "DeletingAddr"
case "DeletingAddr"
Call deleteAddr(params)
Call listAddrs()
myState = "ListingAddrs"
End Select
case "UpdateAddr"
Call updateAddrRecord(params)
Call listAddrs()
myState = "ListingAddrs"
Case "Cancel"
If myState = "ListingAddrs" Then
Response.Redirect("homepage.asp")
Else
Call listAddrs()
myState = "ListingAddrs"
End If
Case Else
Call listAddrs()
myState = "ListingAddrs"
End Select
session("state") = myState
----
Now that's pretty much the whole program. I'll show an example
subroutine call to one of the display forms so that you can see the
linkage through the state and event variables.
----
<%
Sub displayAddAddrForm()
Call displayHtmlHead("Adding Address")
%>
<form action="<%=myName%>" method="get" id="form1" name="form1">
<input type="hidden" name="event" value="">
....HTML to display the form and accept the parameters...
<input type="button" id="button1" name="button1" value="AddAddr"
onclick='form1.event.value="InsertAddr";form1.submit();'>
<input type="button" id="button1" name="button1" value="Cancel"
onclick='form1.event.value="Cancel";form1.submit();'>
</form>
<%
Call displayHtmlTail()
End Sub
%>
----
The other subs either are the same thing, or are simply database access
routines to save the data. Personally, I usually put each sub in it's
own include file for reuse, but you could just tack them all on after
the main page code.
Study this and then if you have questions, ask away.j
-- Rick