Login | Register   
RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX


Top 10 Annotations and Remarks about the Wonderful and Powerful New Features in ASP.NET 2.0 : Page 4

This article discusses 10 features of ASP.NET 2.0 from a real-world perspective. It is not a core reference of classes and methods, but a user's guide with suggestions and trade-offs.

#7—Cross-Page Posting
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 attribute.

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 or QueryString 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 interface—Button, 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" Text="Click" PostBackUrl="target.aspx" /> </form>

When the PostBackUrl property is set, the ASP.NET runtime binds the corresponding HTML element of the button control to a new JavaScript function. Instead of using our old acquaintance __doPostback, 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 TextBox t; 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.

<%@ PreviousPageType VirtualPath="crosspostpage.aspx" %>

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 approach—less data moved, same effect.

#8—Script Callbacks
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.

This enables server-side platforms like ASP.NET to generate script code to execute server tasks without leaving the current page. When the operation completes, results are carried back as plain strings to the client and a Javascript callback takes care of refreshing the user interface of the page (or a control) using the Dynamic HTML object model supported by the browser.

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 browsers—Pocket 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.

AJAX.NET is an open-source library that is gaining popularity these days because it lets you do server-side programming from the client in a more structured way. AJAX.NET provides two key benefits over the ASP.NET callbacks. First, it allows you to pass real objects to the Javascript callback instead of plain strings. Second, it automatically generates any script code that's needed.

By the time you read this, Microsoft should also have disclosed a lot of details regarding Atlas—the ASP.NET 2.0 next (and more structured) version of script callbacks.

Regarding the use of script callbacks—whatever library you use—there 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.

Comment and Contribute






(Maximum characters: 1200). You have 1200 characters left.