Implementing a Wizard

In a Web application, you often need to walk the user through a series of steps—for example, to set up a new account—to gather information for the application. This type of user interface is typical in Windows applications. The user is presented with a set of pages that break down the bigger task into a series of steps; these steps collect smaller sets of input. When the user finishes the final step in the set, all the information has been gathered, and the task is completed.

In this section, we’ll walk through two approaches for implementing the wizard functionality easily in ASP.NET. There are pros and cons to both, so you might need only one or a combination of approaches to accommodate your needs.

The first approach is to use a single page that leverages view state. The data being gathered is sent along in the response for each request and returned on each postback. Code Listing 1-12, SinglePageWizard.aspx, is an example of a single-page wizard. The page is constructed of several panels; each panel represents a single step in the wizard. In this example, we gather only the user’s name in Step 1 and his favorite hobby in Step 2. The final panel displays the results gathered. On each request, we explicitly set the panel’s visibility so that the user is viewing only a single wizard step.

Code Listing 1-12: SinglePageWizard.aspx

 <%@Page language="c#" runat="server" %>
<script runat="server">
protected void Page_Load(object o, EventArgs e) {
    step1.Visible = false;
    step2.Visible = false;
    step3.Visible = false;
    if(!IsPostBack) {
        step1.Visible = true;
        return;
    }
}
 
protected void ClickStep1(object o, EventArgs e) {
    step2.Visible = true;
}
 
protected void ClickStep2(object o, EventArgs e) {
    theFinalName.Text = theName.Text;
    theFinalHobby.Text = theHobby.Text;
    step3.Visible = true;
}
</script>
 
<form runat="server">
 
<asp:panel  runat="server">
    Name: <asp:textbox  runat="server" />
    <asp:button type="submit"  runat="server" Text="Go"
        onClick="ClickStep1"/>
</asp:panel>
 
<asp:panel  runat="server">
    Hobby: <asp:textbox  runat="server"/>
    <asp:button type="submit"  runat="server" Text="Go"
        onclick="ClickStep2" />
</asp:panel>
 
<asp:panel  runat="server">
    Done!<br />
    Name: <asp:label  runat="server" /><br/>
    Hobby: <asp:label  runat="server" /><br/>
</asp:panel>
 
</form> 

Because the wizard is a single page, the approach in Code Listing 1-12 has both advantages and disadvantages. One advantage is simplicity. A small wizard can easily be implemented on a single page; it doesn’t have to take explicit action along the way to store the accumulated input in session state or a back- end database. Be aware that the data is carried in a hidden field of the HTML form managed by the ASP.NET run time called view state. For every variable accumulated in the wizard, the size of the view state will grow. This isn’t really a concern for user input of reasonable size, but as the amount of data being gathered grows, an increasing view state might become a concern. The size of data being carried along with each request can be problematic because it has an impact on performance and download time, particularly when the user has a slower connection.

In addition to the potentially large view state size, all the control values must be carried between client and server on postbacks, meaning that the control must be present in the control tree. This can be a limiting factor. Controls created dynamically that are part of the wizard will need to be created on each request—even when the controls are in an invisible panel, they need to be part of the control tree. There is a certain performance hit both in terms of memory usage and execution overhead for the controls to be instantiated and participate in the page processing. As the complexity of the wizard grows, so does the size of the page, so we’ll explore another option for gathering user input.

The second approach to writing a wizard moves us beyond the single page scenario. Just as in Active Server Pages, ASP.NET provides intrinsic support for session-oriented storage. In Chapter 5, we will look more closely at the different options for configuring session state support, ranging from the fastest in-process option to back-end database storage that supports a Web farm. We’ll also look at how it can be configured to scale from the fastest in-process support to Web farm configurations with persistent storage and even higher reliability. For this example, we aren’t concerned about how session state is configured; we just need it to allow us to accumulate data for a single user as he progresses through the wizard, without restricting him to a single page. For simplicity, we will duplicate the single-page wizard in multiple pages. In Code Listing 1-13, MultiPageWizard_PageOne.aspx, the first page of the wizard gathers only the user name. Notice that we aren’t using a panel server control as we did in SinglePageWizard.aspx to control visibility of the various steps. Instead, when the page is posted back, we store the data in session and use Server.Transfer to get to the next step.

Code Listing 1-13: MultiPageWizard_PageOne.aspx

 <%@Page language="c#" runat="server" Debug="true" %>
<script runat="server">
protected void Page_Load(object o, EventArgs e) {
    if(IsPostBack) {
        Session["theName"] = (string)theName.Text;
        Server.Transfer("MultiPageWizard_PageTwo.aspx", false);
    }
}
</script>
 
<form runat="server">
    Name: <asp:textbox  runat="server" />
    <asp:button type="submit"  runat="server" Text="Go"/>
</form> 

After the user enters his name and clicks the button to submit the form, the IsPostBack property is true. The value of the text box is stored in session, and the user is transferred to MultiPageWizard_PageTwo.aspx, as shown in Code Listing 1-14.

Code Listing 1-14: MultiPageWizard_PageTwo.aspx

 <%@Page language="c#" runat="server" %>
<script runat="server">
protected void Page_Load(object o, EventArgs e) {
    if(IsPostBack) {
    Session["theHobby"] = theHobby.Text;
    Server.Transfer("MultiPageWizard_PageFinal.aspx");
    }
}
</script>
 
<form runat="server">
    Hobby: <asp:textbox  runat="server"/>
    <asp:button type="submit"  runat="server" Text="Go"/>
 </form>

MultiPageWizard_PageTwo.aspx is essentially the same as MultiPageWizard_PageOne.aspx. Again, we take the hobby information submitted by the user and add it to the values being accumulated in the HttpSession object.

Tip

Add validators to the wizard pages that verify the set of expected values is in session. If all the required values aren’t present, redirect the user to the step where the first missing piece is to be submitted.

In Code Listing 1-15, MultiPageWizard_PageFinal.aspx, we pull the accumulated values out of session and, for the sake of the example, display them. In a real-world wizard, you would no doubt have more values to collect and would be performing some action with a back-end database.

Code Listing 1-15: MultiPageWizard_PageFinal.aspx

 <%@Page language="c#" runat="server" %>
<script runat="server">
protected void Page_Load(object o, EventArgs e) {
    theFinalName.Text = (string)Session["theName"];
    theFinalHobby.Text = (string)Session["theHobby"];   
}
 
</script>
 
<form runat="server">
Done!<br />
    Name: <asp:label  runat="server" /><br/>
    Hobby: <asp:label  runat="server" /><br/>
</form> 

Of course, as with the single-page wizard, there are pros and cons to the multi-page version. The data submitted by the wizard is stored in session state, which utilizes more server resources, but it avoids the need to send potentially significant quantities of data back and forth between the browser and the server. The default time-out for individual sessions is 20 minutes, so a user who gets distracted in the middle of his session can find that the data he already submitted is no longer available.

Tip

Add validators at each step of the wizard to enforce the entering of correct input by the user. For more information on validators, see “Controls for Validating User Input” in Chapter 2. Let the user proceed only after the values accumulated to that point are satisfactory and errors are corrected, because gathering missing information becomes more complicated after the user reaches the end of the wizard.