1

I am getting used to the Post/Redirect/Get pattern, I find it a very good procedure and it also seems to get me thinking more about page structure and not relying on ASP.Net events too often.

I am currently writing a wizard feature for a site, though not using the ASP.NET Wizard control, but handling it more manually with a MultiView. Typically in the past I would have expected the typical user experience to be GET > POST > POST > POST etc. for each successive step of the wizard. However I am now thinking of using a more P/D/G approach, do people often do this with their wizards?

My current thinking is that once a step has been completed by a user and they choose to continue, my session object containing the current wizard information will be saved back to the session and then a GET redirect will be made back to the wizard page. When the wizard page loads the Session object is interrogated to determine the correct step to display to the user.

I can see two good advantages with this:

  1. that it comes with the usual benefit of P/R/G and it eliminates the Refresh problem and also
  2. a user can navigate away from the wizard and come back to it (if their session is still active) and they will be taken straight to the correct step.

Do people consider this a cleaner design? Are there obvious drawbacks? I'm thinking I might be turning into more of a cynical programmer and trusting ASP.Net and the Postback lifecycle less, but it's not as if this approach will result in much more code? If I didn't implement it I'd have to write in all the checks against a user refreshing or trying to navigate to steps they shouldn't anyway.

Kristijan Iliev
  • 4,901
  • 10
  • 28
  • 47
Kasaku
  • 2,192
  • 16
  • 26

2 Answers2

1

One problem with the approach as you have described it is there is no 'back' functionality, which is a typical expectation with Wizards. Also, be aware that someone may expect to be able to progress through multiple 'sessions' of the wizard at the same time in different browser tabs, and your system would prevent that.

The 'Back' functionality can be included with a special Query String value put in the 'Back' link/button which instructs the session-stored object to back things up a step. The multiple-instance in one session would require something more involved; perhaps simply storing the data in the view state, or creating a key for the 'wizard instance'. Or, you may decide to only support a single instance of the wizard to run at any one time. (admittedly, it may be an extremely rare case that someone tries to run multiple wizard instances at once, anyway)

Andrew Barber
  • 39,603
  • 20
  • 94
  • 123
  • Thanks for the response. The wizard in question is a payment procedure, they wouldn't be able to run multiple sessions of it. When each postback is occurs to complete a step it will prevent it from happening again (so they couldn't say, try to complete payment twice in two different tabs). – Kasaku Dec 03 '10 at 15:48
  • For the back functionality, I am allowing them to revisit old steps to amend details. The status that I am holding would reflect a "latest status", so they would be permitted to visit any step that leads up to that step to amend data. – Kasaku Dec 03 '10 at 15:49
1

Yes this is a cleaner design.

The only drawbacks are the additional roundtrip (for the redirect) and the slightly increased complexity of displaying status messages.

I never return POST results to users anymore.

Community
  • 1
  • 1
Jeff Sternal
  • 47,787
  • 8
  • 93
  • 120
  • I was still considering letting POST results go back to the user on validation failures to display the error messages in an easier fashion. Since in that instance no domain model will be updated, so a repeated POST attempt should be of no consequence? I typically use the redirect just for successful POSTs, should I rethink this? – Kasaku Dec 03 '10 at 15:59
  • I prefer not to do that, because it requires additional conditional logic in your pages that makes them harder to maintain, but it's probably defensible (particularly as an intermediate step). Lately I've just been using a message `Stack` in the user's session for this sort of thing. (ASP.NET MVC has something similiar in `TempData`.) – Jeff Sternal Dec 03 '10 at 16:01