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.
Dig Deeper on ASP.NET development best practices
Related Q&A from Daniel Cazzulino
Here Daniel Cazzulino explains how to load a DSL (domain specific language) domain model instance file programmatically. This requires the .NET type ... Continue Reading
Here we offer a glimpse at 12 of .NET development expert Danny Cazzulino's top ASP.NET questions and answers. Continue Reading
C# developers should NOT be modifying InitializeComponent method in the code-behind (or any of the variable definitions) by hand. Continue Reading
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.