• Choose a category
• All
• Classic-Fiction

The ASP.NET framework offers a built-in mechanism to override the normal processing cycle and let the page post to another, distinct page. In general, postbacks occur in either of two ways—through a submit button or via script. The client browser usually takes on any post conducted through a button and automatically points to the page that the action attribute of the posting form indicates. A lot more of flexibility is possible when the post occurs via script.

In ASP.NET, however, you can also configure certain page controls—in particular, those that implement the IButtonControl interface—to post to a different target page. This is referred to as cross-page posting.

Posting Data to Another Page

Authoring a Web page that can post data to another page requires only a couple of steps. First, you choose the controls that can cause the postback and set their PostBackUrl property. A page can include one or more button controls and, generally, any combination of button controls and submit buttons. Notice that in this context a button control is any server control that implements IButtonControl. (I fully covered the IButtonControl interface in Chapter 6.) The following code snippet shows how to proceed:

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. The button renders the following markup:

value="Click"

onclick="javascript:WebForm_DoPostBackWithOptions(

new WebForm_PostBackOptions("buttonPost", "",

false, "", "search.aspx", false, false))" />

As a result, when the user clicks the button, the current form posts its content to the specified target page. What about the view state? When the page contains a control that does cross-page posting, a new hidden field is also created—the __PREVIOUSPAGE field. The field contains the view state information to be used to serve the request. This view state information is transparently used in lieu of the original view state of the page being posted to.

You use the PreviousPage property to reference the posting page and all of its controls. Here’s the code behind a sample target page that retrieves the content of a text box defined in the form:

// This code belongs to doSearch.aspx

protected void Page_Load(Object sender, EventArgs e)

{

// Ensure this is a cross-page postback

if (PreviousPage == null)

{

Response.Write("Must be a cross-page post.");

return;

}

// Retrieves posted data. This ensures PreviousPage is not null.

var txt = (TextBox) PreviousPage.FindControl("Keyword");

...

}

By using the PreviousPage property on the Page class, you can access any input control defined on the posting page. Access to input controls is weakly typed and occurs indirectly through the services of the FindControl method. The problem here lies in the fact that the target page doesn’t know anything about the type of the posting page. PreviousPage is declared as a property of type Page and, as such, it can’t provide access to members specific to a derived page class.

Furthermore, note that FindControl looks up controls only in the current naming container. If the control you are looking for lives inside another control (say, a template), you must first get a reference to the container, and then search the container to find the control. This happens commonly when you employ master pages. To avoid using FindControl altogether, a different approach is required.

What about using the dynamic type in ASP.NET 4? It might work, but this solution also has a little drawback—the same drawback we encountered in Chapter 8, for master pages. The problem is that you can’t access, say, the Keyword text box control from within the posted page because the Keyword