Programming Microsoft ASP.NET 4 - Dino Esposito [6]
More Control over HTML
To code AJAX features, developers need to make clear and reliable assumptions about the structure of the Document Object Model (DOM) displayed within the browser. It turns out that smart black boxes, which are what ASP.NET server controls were initially conceived as, are no longer ideal tools to build Web pages.
Developers need to be sure about the layout of the HTML being output; likewise, developers need to control the ID of some internal elements being inserted into the resulting DOM. The adoption of the Web model in a large area of the industry and the public sector has resulted in the creation of applications with a potential audience of a few million people—not necessarily power users, perhaps users with disabilities, and not necessarily users equipped with the latest version of a given browser. And still developers are tasked with ensuring that all of this heterogeneous audience has the best experience and a common interface.
As you can see, the advent of AJAX brought about the complete turnaround of one of the ASP.NET pillars. Originally designed to favor independence from HTML, ASP.NET is now asked to favor a programming model that heralds total control over HTML. As you’ll see in the rest of the book, although this is far from being a mission-impossible task, it requires you to pay much more attention to how you configure controls and design pages. It also requires you, on your own, to attain a lot more awareness of the capabilities of the platform.
Separation Between Processing and Rendering
ASP.NET made the Web really simple to work with and made every developer a lot more productive. To achieve this result, ASP.NET was designed to be UI focused. All you do as a page developer is author pages and the code that runs behind the page.
The page gets input; the page posts back; the page determines the output for the browser. The underlying model leads you to perceive any requests simply as a way to generate HTML through a page. The page entity dwarfs anything else; you don’t really see any correspondence between a request and a subsequent server action. All you see is an incoming HTTP request and a server page object that takes care of it and returns HTML.
In this model, there’s no clear separation between the phase of processing the request to grab raw data to be incorporated in the response (for example, a list of records to be displayed in a grid) and the phase of formatting the raw data into an eye-catching, nice-looking layout.
Again, you’ll see in the rest of the book that achieving separation between processing and rendering is definitely possible in ASP.NET Web Forms and is not at all a mission-impossible task. However, it requires that you pay a lot more attention and have more discipline when it comes to writing pages and the code behind pages. Figure 1-2 extends the schema of Figure 1-1 and provides a more detailed view of the page-based pattern used to process requests in ASP.NET Web Forms. (I’ll return in a moment to the Page Controller pattern.)
Figure 1-2. ASP.NET request processing and HTML rendering.
The entire processing of an HTTP request is done by progressively updating the state of the server controls the page is made of. At the end of the cycle, the current state of controls is flushed to the response output stream and carried to the browser. The entire cycle is based on the idea of building a page, not performing an action and showing its results.
For years, this aspect of Web Forms was just accepted for what it was, with no special complaints and some praises. Today, the growing complexity of the business logic of applications built on top of the ASP.NET platform raises the need for unit tests and static analysis that are harder to set up in a runtime environment strongly focused on the plain UI.
Again what was a huge winning point in the beginning is now