Almost every Web developer moving to ASP.NET from classic ASP found, in the beginning, that it was quite weird to be limited to a single form. More exactly, ASP.NET requires that only one server-side form is enabled at a time. You can place multiple server forms on an ASP.NET page so long as only one is active. You can also place as many client HTML forms as needed with no sort of limitation. A client HTML form is a <form>
tag devoid of the runat=server
Multiple forms are useful to implement common features such as a search or a login box. On the other hand, the single form model was chosen as one of the pillars of ASP.NET because it forces page self-posting and makes the implementation of cross-request state dramatically easier. In ASP.NET 1.x, posting to another page is possible only using client HTML forms or redirecting the browser to the desired page after storing parameters to the session state. If you post using a client HTML form you can't use viewstate
and the type-safe programming model of ASP.NET; you are forced to use the Request's Form
collections as in classic ASP.
In ASP.NET 2.0, you'll find a more structured approach to cross-page posting that, although different from classic form posting, allows you to pass values to another page through the ASP.NET postback mechanism.
In ASP.NET 2.0, you can instruct certain button controls to post to a different target page. Button controls that support cross-page posting are those that implement the IButtonControl interfaceButton, ImageButton, and LinkButton controls.
Authoring a Web page that can post data to another page requires only a couple of steps. First, you choose the controls that can post back and set their PostBackUrl
property to the desired target URL. Here's how to proceed.
<form id="form1" runat="server">
<asp:TextBox runat="server" ID="Data" />
<asp:Button runat="server" ID="buttonPost"
When the PostBackUrl
, it uses the new WebForm_DoPostBackWithOptions
function. As a result, when the user clicks the button, the form posts its content to the specified target page.
What about the viewstate
? When the page is enabled for cross-page posting, a new hidden field is also created named __PREVIOUSPAGE
. The field contains the viewstate information to be used to serve the request to the new page. This viewstate
information is transparently used in lieu of the original viewstate
of the page being posted to.
You use the new PreviousPage
property to reference the posting page and all of its controls.
void Page_Load(object sender, EventArgs e)
// Retrieves posted data
t = (TextBox) PreviousPage.FindControl("Data");
Access to input controls is weakly typed and occurs indirectly through the FindControl
method because the target page doesn't know anything about the type of the posting page.
If you know exactly who will be calling the page, you can flag the target page with the @PreviousPageType
directive. This causes the PreviousPage
property to be typed to the right source page class.
Passing values from one page to another is a task that can be accomplished in a variety of ways-using cross-page posting, server transfer, HTML forms, or query strings. Which one is the most effective for developers?
Note that in ASP.NET 2.0, cross-page posting as well as server transfers (the Server.Transfer
method) offer a familiar programming model but potentially move a significant chunk of data through the __PREVIOUSPAGE
field. In other words, these approaches send values for all the input fields in the source page. In many cases, the target page just needs to receive a few parameters to start working. If this is the case, HTML client forms might be more effective in terms of data being moved. HTML forms, though, require an ASP-like programming model. In my opinion, all considered this is the most effective approachless data moved, same effect.
All Web developers dream of an environment that allows them to execute code on the server and update the page without a full refresh. This kind of feature is not natively part of the HTTP world so to get it working you must be ready to pay some price. In first place, you need a browser that can issue HTTP calls out of band. Internet Explorer 5.0 and newer versions come equipped with an ActiveX component named XmlHttpRequest. In spite of the name that evokes XML stuff, this object is nothing more than a thin object model built around the HTTP protocol. There's nothing related to XML in what it does except perhaps the fact that it can carry XML data. Loving this object released in the spring of 1999, the Mozilla team created a clone named XmlHttpRequest and baked it in the DOM of Mozilla browsers. Recently, Opera also did the same so that today virtually all browsers have the capability of issuing HTTP command out of band.
ASP.NET 2.0 provides this feature through script callbacks, which is an interface that pages and/or controls implement to favor out-of-band calls. When enabled, the feature forces the ASP.NET runtime to inject some tailor-made script code to trigger the remote call.
Script callbacks work nicely in ASP.NET 2.0 and are not that hard to implement in ASP.NET 1.x. Check out the "Cutting Edge" column in the August 2004 issue of MSDN Magazine for an example. The rub lies in the fact that in their native form, script callbacks add yet another layer of code to your application. It's not object-oriented code; it's not modular code; it's simply a tangle of function calls and methods that span the client and the server. But it works on a good number of browsersPocket Internet Explorer is the most popular browser for which it poses some issues. NetFront is an alternate Pocket PC browser that overcomes the limitation of Pocket Internet Explorer.
By the time you read this, Microsoft should also have disclosed a lot of details regarding Atlasthe ASP.NET 2.0 next (and more structured) version of script callbacks.
Regarding the use of script callbackswhatever library you usethere are two considerations to bear in mind regarding security and page creation. Users navigating with Internet Explorer browsers have to lower the security level to allow at least for ActiveX control calls safe for scripting. This is not required on other browsers. In all cases, you must be able to merge the return values of server calls with the DOM of the current browser. This means that you must stay close to the methods and properties in the W3C HTML 4.0 standard.