Question

I imagine this is a pretty hard question to answer without sitting down and looking at all the source code, but I figured I’d post it anyway and see if you all had any conceptual thoughts on a process we’re using in my company.

The project I’m working on currently is a self-registration page for our end users. Previously, we used 3 separate ASP.NET wizard controls for each of our different registration processes. It was consistantly stated by our customers that the process was very confusing, and they never knew which of the three different processes they should be completing. So after being asked to compile the three apps into one, I quickly found that the registration wizard controls are not very extensible. The new process needed to be very dynamic, so the static, one path, wizards were not fulfilling the needs.

So in an attempt to make a more dynamic process, I rolled my own registration app that relies on session state to walk a user through registration. The way I have it set up currently is using binary flag values for possible steps in the registration. I then have a integer value in SessionState that I update after a user completes a step.

Example:

  const int accountNumberStep = 1; const int userPassStep = 2; const int usernameReclaimStep = 4;   /* code snipped */   // Code at the end of step Username/Password selection // at the end of Username/Password selection step, update session state to record that step was finished SessionState('stepsCompleted') = (int)SessionState('stepsCompleted') | userPassStep;   /* code snipped */   // Code at the beginning of each step to verify previous step was completed if (!((int)SessionState('stepsCompleted') & userPassStep == userPassStep)) {     RedirectToPreviousPage(previousStep:=userPassStep); }  

Another major piece of this (this is where the dynamic piece comes into play) is using a session variable to keep track of the type of registration they are going through. In other words, they might have three different types of registration they can go through:

1. Normal Registration
2. Account Update Registration
3. Obtain Disabled User Account Registration

The registration type the user is completing is determined as they progress through the registration. For example, after a user types in there account number, I determine that they are not a new user, so they will be either an update, or a re-enable. This path is stored in the registration type variable in session state.

The final major piece of the app tracks text box values, radio box selection, etc. This is all stored in the SessionState as well, so if at any point in the process, the user wishes to back up a step or two, they will not lose the previous values they entered. These values are also used in the final step of the registration process in which the customer is actually registered on the back end database.

As you can see, all of this is vary similar to what an ASP.NET wizard control does. With the exception of the registration type variable. This allows me to branch the registration into different paths at any given point in the process.

Anyway, sorry again if this is confusing. I’m mainly hoping someone will come by that has done something similar and might be able to give me some advice.

Thanks in advance for your help.

CJAM

Answer 1

The wizard control is based on the MultiView control, which basically provides a means of showing one (and only one) view at a time. The only difference is that you are required to control navigation manually with the MultiView, therefore allowing you non-linear progression through the steps.

With the MultiView, the values of all controls in all the views will be stored in the ViewState, so there is no need to store them in the Session. Buttons within each view can post back, and based on the values of other controls, you can show a specific view.

Check out the ASP.NET Quickstart on MultiView and View controls