Overview
The ASP.NET Control/PostBack Architecture is excellent for most Web development. However, there are a few limitations that can sometimes be quite significant. One of the most fundamental problems has been the restriction to one server Form. Another similar issue has been the fact that server Forms must always PostBack. This article is a review of one solution to these problems: the WilsonWebForm. Note that this merits a disclaimer -- I am selling this Form control for US$50, although a
free Demo version is available that works in VS.NET and Web-Matrix.
Multiple Server Forms
The standard html Page has no limitations on the number of Form elements used, and Classic ASP developers could even have several independent Forms on Pages. However, ASP.NET does not allow multiple server Forms on the same Page at all, and although there are good reasons for this, sometimes this isn't desirable. The reasons for wanting multiple Forms on a web Page vary from the very simple Search Form to more complex cases where users have two options available to them. I have also seen many developers wanting a separate Form, along with Controls and all the associated Events, in reusable User Controls, but without success. Using non-server standard html Forms is usually not an option for this issue, since the ASP.NET PostBack Event Architecture requires the Form's ViewState. Even if you were willing to forgo ASP.NET Events, and other ViewState bonuses, you would not be able to use any WebControls (<asp:*>) without a server Form. So the accepted answer to this limitation of ASP.NET has been to just accept it, which understandably is not always acceptable, even though it often works well.
The WilsonWebForm is a Server Form Control that overcomes all these limitations, so users of this Control can have multiple server Forms on their ASP.NET Pages. It allows any Control, even WebControls, to be used in this Server Form Control, with the exception of Validator Controls, unlike the non-server html form tags. You can also combine a single built-in ASP.NET server Form with WilsonWebForms, so that they can be used side-by-side when you do need some Validator Controls. This server Form Control fully supports the ASP.NET PostBack Event Architecture, and it also supports ViewState so everything you expect should continue to work. It does require that your Pages ultimately inherit from the Wilson.WebForm.Page base class, instead of System.Web.UI.Page, but even this gives you some extras. For instance, not only does each WilsonWebForm have a IsPostBack Boolean Property, but the Page itself now has a PostBackForm String Property with the Form's ID. It also gives you the option of ViewState saved in Session or in Hidden Fields, which you can set globally in the Web.config file and/or override in each Page.
Listing 1: Multiple Server Forms
<%@ Page Inherits="Wilson.Web.Page" %>
<%@ Assembly Name="WilsonWebForm" %>
<%@ Register TagPrefix="Wilson" Namespace="Wilson.WebForm" Assembly="WilsonWebForm" %>
<html>
<head>
<title>WilsonWebForm Demo: Multiple Server Forms</title>
</head>
<body>
<Wilson:Form id="frmWilsonForm" runat="server">
<ASP:TEXTBOX id="txtWilsonValue" runat="server"></ASP:TEXTBOX>
<P />
<ASP:BUTTON id="btnWilsonSubmit" runat="server" text="Submit"></ASP:BUTTON>
</Wilson:Form>
<Form id="frmBuiltInForm" runat="server">
<ASP:TEXTBOX id="txtBuiltInValue" runat="server"></ASP:TEXTBOX>
<P />
<ASP:BUTTON id="btnBuiltInSubmit" runat="server" text="Submit"></ASP:BUTTON>
</Form>
</body>
</html>
Non-PostBack Forms
The standard html Form element has an Action attribute that specifies what Page, or even general URL, the Form will submit its input data to for its processing. However, the ASP.NET server Form ignores anything that is set for the Action, and forces the Form, and its associated Page, to always "PostBack" to itself. There are certainly some valid reasons that Microsoft had for this restriction, but there are also some very good reasons to sometimes not want this behavior. These reasons typically include small site-wide Forms, such as login or search, as well as critical cases when data must be posted to another site altogether. The standard ASP.NET solution to these problems has been to use either Redirect, or to step out of the Control Architecture and create a standard html Form tag. The Redirect solution works for many cases, although often not for cross-site, and it lacks the separate default buttons which is normal with html Form tags. The html Form solution solves these issues, but it requires manual html coding, especially since WebControls (<asp:*>) are not allowed outside of server Forms.
The WilsonWebForm is a Server Form Control that does expose an Action attribute, so users of this Control will be able to post data to other Pages, or even URLs. It allows any Control, even WebControls, to be used in this Server Form Control, with the exception of Validator Controls, even easily reused as User Controls. This makes it easy to create small site-wide Forms, like login or search Forms, that each have their own default buttons and that post to the appropriate pages. More importantly, this makes it easy to post your own input data to other sites, which may not have been possible with the simple Redirect solution in ASP.NET. This may be necessary to accommodate credit-card or PayPal payment processing, or simply desirable to invoke a Google search or Weather lookup from your site. Keep in mind that you still need to carefully evaluate each Control used here, for example, the Calendar WebControl doesn't really work well without PostBacks. Also, while I haven't noticed that ViewState actually breaks non-PostBack Forms, it certainly has no value here, so you should test it and probably disable it.
Listing 2: Non-PostBack Forms
<%@ Page Inherits="Wilson.Web.Page" %>
<%@ Assembly Name="WilsonWebForm" %>
<%@ Register TagPrefix="Wilson" Namespace="Wilson.WebForm" Assembly="WilsonWebForm" %>
<html>
<head>
<title>WilsonWebForm Demo: Non-PostBack Forms</title>
</head>
<body>
<Wilson:Form id="frmNonPostBack" runat="server" action="OtherPage.aspx">
<ASP:TEXTBOX id="txtSearchValue" runat="server"></ASP:TEXTBOX>
<P />
<ASP:DROPDOWNLIST id="drpSearchField" runat="server">
<ASP:LISTITEM value="1">ASP.NET</ASP:LISTITEM>
<ASP:LISTITEM value="2">C#.NET</ASP:LISTITEM>
<ASP:LISTITEM value="3">VB.NET</ASP:LISTITEM>
</ASP:DROPDOWNLIST>
<P />
<ASP:BUTTON id="btnSearch" runat="server" text="Search"></ASP:BUTTON>
</Wilson:Form>
</body>
</html>
Conclusion
The WilsonWebForm is an Advanced ASP.NET Server Form Control that overcomes the limitations of having only one server Form and also always required a PostBack. It plugs nicely into the existing ASP.NET Page Architecture, allowing WebControls and fully supporting the PostBack Events and ViewState you've come to expect now. Try for yourself the
free Demo version that fully works in VS.NET and Web-Matrix. Note that the licensed WilsonWebForm is not free, it is sold on my site for US$50. There is also an
on-line Demo and full product
Documentation that is available.
Author Bio
Paul Wilson is a software architect in Atlanta, currently with PRG-Schultz. He specializes in Microsoft technologies, including .NET, C#, ASP, SQL, COM+, and VB. His
WilsonWebForm Control allows Multiple Forms and Non-PostBack Forms in ASP.NET. He is a Microsoft MVP in ASP.NET and is also recognized as an
ASPInsider. He is a moderator on Microsoft's
ASP.NET Forums, as well as one of the top posters. He is holds the MCSD, MCAD, MCDBA, and MCSE certifications. Please visit his website,
www.WilsonDotNet.com, or email him at
Paul@WilsonDotNet.com.