Yep - possible. It's quite common to see both methods used. If you're going
to bung everything in the one page then plan it first - map your workflow
using a state transition chart for anything but the most trivial sites. It's
really easy to find examples of where this approach has been used and the
different page views are just implemented using in-line conditional
statements - makes for very hard-to-read code.
The problem with using multiple physical pages is that it's common to see
variables persisted in the querystring or form as you move from page to
page. This makes your data a bit more visible (esp. if using the QS). To
overcome this you can whack it into the Session or a database instead. The
Session requires some thought due to users' use of the Back and Forward
browser buttons, and persisting to a database can complicate your code and
your database structure. Each method has unique advantages and
disadvantages.
If you're going to use the single-page method then think of each page-view
as a state, and the act of clicking a button (etc.) as an event. A common
approach is to pass a value representing each of these two things from 'page
to page' (only one page), detect the state, detect the event and then
display the page accordingly. Each form's processor is at the start of the
next page so you can normally get away with posting from one page to the
other keeping your data out of the QS - i.e. the form submits to itself.
Retrieving the state and event may require use of the QS and/or form
depending on what your events are.
In the code below notice the call to SaveFormData. Make sure you put all of
your logic into functions and subs. There is nothing worse than trying to
debug 1000 lines of someone else's spaghetti when they have used one ASP to
render multiple page views.
Untested code follows. Have a go.
Dim State
Dim Event
State = Request.Form ("S") ' Will be previous page's state.
Select Case State
Case STATE_ENTERNAME
' Our events are our two button clicks. Decode and store the event
first just to keep things tidy.
' Could put the code in these conditionals if you like.
If (Request.Form("cmdSubmitSave") <> "") Then
' Save button clicked.
Event = EV_SAVEDATA
ElseIf (Request.Form("cmdSubmitBack") <> "") Then
' Back button clicked.
Event = EV_BACKTOPREV
End If
' Now take action.
Select Case Event
Case EV_SAVEDATA
' Retrieve and save form data.
SaveFormData ...
Case EV_BACK_TO_PREV
' Redirect to the previous page in the workflow.
Response.Redirect ....
Case Else
' Came from the STATE_ENTERNAME state without an event.
Error condition??
End Select
Case STATE_ENTERSHIPPINGTO
' You get the idea.
Case Else
' Default form view. This is the case that's executed by default.
' It could also be used to handle error conditions.
End Select
Alan
