Q
Problem solve Get help with specific problems with your technologies, process and projects.

Extending a lengthy Web form over serveral pages in ASP.NET

I have a Web form that is rather lengthy. I would like to have it extend over several pages, but there doesn't seem to be a good way to do this with ASP.NET.

In ASP 3.0, it was simple to have a form submit to "the next page" while keeping the visitor state in session variables (or otherwise). But in ASP.NET, there seems to be only three appropriate patterns, none of which are very clean:

1. If IsPostBack, use Server.Transfer with the preserveForm attribute.

This keeps the form data and executes a new page, but now the Back button (in IE) performs unexpectedly since the URL hasn't changed. Plus, after the second page, it gets complicated transferring to the correct "next page."

2. Save the Form data in the HTTPContext object and redirect to the next page.

This is an ugly solution since it requires twice as many browser requests as should be necessary.

3. Use the asp:panel control and consolidate all pages of the form into one giant page.

This appears to be the preferred ASP.NET way to do this, but in practice becomes messy. Consider that the reason the form is split across several pages to begin with is because it is too long for one page. Asp:panel solves the UI problem, but not the code design problem. The code-behind page, in my case, will have over two hundred declarations of checkboxes and drop-down lists alone; this is not to mention the fact the we still manually have to set the visibility of each panel as the user progresses through the form. In the end, it feels too contrived to be a good design.

None of these options seem meant for the purpose of handling multi-page forms. After extensive googling, I found an article by Andy Elmhorst that involves creating a custom IHttpHandler to solve this problem. After looking at that interface, I think that solution would be unlikely -- and since the article costs money to read, I'm not sure I want to find out. What are your thoughts on this issue?
I share most of your concerns. But they are solved quite easily, and almost the same way you did in ASP days. First, an observation: your second "solution" wouldn't work with redirects, it requires a Server.Transfer, because HttpContext is "transient state" in the sense that it only spans the life of a single request. Second, this solution actually WORKS. If you do a Server.Transfer to another page, storing the relevant state in HttpContext.Items, the browser will correctly "back" to the first one automatically.

You can actually post a form to a different one, which involves writing a trivial class inheriting HtmlForm and using it instead of the default <form> tag, for example, <my:form>. You can expose the action as a property at that point. Behavior will not change as extensibility is a natural and foreseen consequence of ASP.NET general arquitecture. You can find such a solution here.

The benefit of HttpContext.Items+Server.Transfer is that you gain greater control over what's needed on the next page, can control whether the transfer is allowed to occur at all (validation), and don't interfere with the built-in postback mechanism, which may be required for some controls to work.

This was last published in October 2003

Have a question for an expert?

Please add a title for your question

Get answers from a TechTarget expert on whatever's puzzling you.

You will be able to add details on the next page.

Start the conversation

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

-ADS BY GOOGLE

SearchCloudComputing

SearchSoftwareQuality

TheServerSide

SearchCloudApplications

Close