• Choose a category
• All
• Classic-Fiction

When it comes to security, don’t look for a magic wand to do the job for you. Security is a state of mind, and insecurity is often the result of loose coding styles, if not true programming laziness. Never blindly trust anything regarding Web and ASP.NET security. Always keep in mind that security for Web applications is mostly about raising the bar higher and higher to make it hard for bad guys to jump over.

Part V. The Client Side

In this part:

Chapter 20

Chapter 21

Chapter 20. Ajax Programming

The free thinking of one age is the common sense of the next.

—Matthew Arnold

Gone are the days when a Web application could be architected and implemented as a collection of static and dynamic pages served from the server for each and every request. In today’s Web, a lot of work is done on the client using JavaScript libraries or richer engines such as Adobe Flash or Microsoft Silverlight.

Having rich client-side functionality is no longer a brilliant exception as it was only a few years ago; this is now going to be the rule. On the other hand, what’s your knee-jerk reaction when you run across a Web site that requires you to pick up an item from a drop-down list and refreshes the entire page afterward? More or less, you hate it and wish they could update the site as soon as possible. In the end, using server-side programming to generate the page markup is more and more becoming a thing of the past.

Server-side programming is still an important piece of the Web, but these days it’s different. For a Web site (a plain collection of mostly read-only pages), you leverage server-side programming to generate markup and serve it to the browser over an out-of-band, script-led request. For a Web application (a more sophisticated composition of functions exposed through pages), you tend to expose a URL-based API from the server that JavaScript code calls back to build and refresh the view dynamically.

The history of Web is full of cycles in which the focus shifts from the client to the server and then back. We had Dynamic HTML (DHTML) in 1997, but only for a subset of browsers—well, mostly Internet Explorer 4. There was no immediate and general consensus around that innovation, which remained confined to a small percentage of browsers for years. Then the hype returned to server programming with ASP.NET Web Forms. It’s odd, when you think of it, how shielding developers from JavaScript and HTML was one of the best-selling points of ASP.NET. Around 2005, people started moving back toward client-side programming with Ajax.

Ajax is an acronym that stands for Asynchronous JavaScript and XML. It’s a blanket term used to describe applications that extensively use the client-side capabilities of the Web browser. The browser is not simply a dummy HTML-based terminal; it gains the power of a real tier that hosts a part of the application’s presentation logic. So how do you do Ajax in ASP.NET?

Pattern-wise, there are two main approaches to Ajax. One consists of serving markup to the browser over a script-led request. Known as HTML Message (HM), this pattern is akin to the classic browser-to-server model except that the request is placed via user-defined script rather than the hard-coded browser’s machinery. As a developer, you make yourself responsible for deciding how to run the request and how to process the returned markup. On the server side, however, any URL you invoke always returns plain HTML markup.

The other pattern is Browser-Side Templating (BST) and is based on the idea that the browser places script-led requests for raw data to be incorporated in the user interface by some script-based presentation logic.

In this chapter, I’ll dig out these two patterns and explore technologies related to ASP.NET Web Forms that make it work.

The Ajax Infrastructure

Typically, Web applications work by submitting user-filled forms to the Web server and displaying the markup returned by the Web server. The client-to-server communication employs the HTTP protocol