This code works just fine but has a major drawback: you can’t use the ASP.NET programming model to retrieve posted data in the action page of the client form. When writing search.aspx, in fact, you can’t rely on view state to retrieve posted values. To know what’s been posted, you must resort to the old-fashioned, but still effective, ASP model, as shown in the following code sample:

public partial class Search : System.Web.UI.Page

{

protected void Page_Load(object sender, EventArgs e)

{

// Use the Request object to retrieve posted data

var textToSearch = Request.Form["Keyword"];

...

// Use standard ASP.NET programming model to populate the page UI

KeywordBeingUsed.Text = textToSearch;

}

}

You use the protocol-specific collections of the Request object to retrieve posted data—Form if POST is used, and QueryString in case of GET. In addition, you have to use the name attribute to identify input elements. Overall, this is perhaps not a recommended approach, but it definitely works. Figure 9-1 shows the page in action.

Figure 9-1. A server form control and a client HTML form working together.

When the user clicks the Search button, the search.aspx page is invoked, the page receives only the values posted through the HTML form, and it uses them to proceed.

Nested HTML Forms

In ASP.NET, most real-world pages are based on master pages. And most of the time the master page includes an outermost tag. This means that if you add a client HTML form element at rendering time the two form elements will be nested.

Now nesting forms is possible in theory, but browsers don’t actually render nested forms properly. The HTML 4 standard prevents direct form-to-form dependency. You are beyond the standard if you add a form element as the direct child of another form. Instead, if you embed the child form within a block element (DIV, FIELDSET), it is considered valid from a syntax point of view. As mentioned, though, the fact is that, regardless of what the World Wide Web Consortium (W3C) believes, browsers just glue the content of the two forms together. As a result, the outermost parent form determines where the post is made.

Nicely enough, although browsers actually seem to produce the same final effect—the content of the inner forms merged with the outermost ones—how that happens is slightly different. For example, if you display a page with nested forms in Firefox 3.6.x, you find out that the child tags are just stripped off. The form content, on the other hand, is preserved. With Internet Explorer 8, the child tag is preserved but it’s closed inline, keeping any content out of it and subsequently merging it to the outermost form.

The code that produces the pages shown in Figure 9-1 descends from the standard ASP.NET 4 template for Web Forms pages with a master. However, because the master contains a tag, I had to rework the master template to be able to use side-by-side tags and avoid nesting.