F9 Group Marketing and Technology Blog

The ASP.NET Web Forms model strives to encapsulate the lower level complexities involved in building a web application. Features like server-side event handlers, the page lifecycle, and view state effectively blur the line between the client and the server, simplify state management, and free the developer from worrying about HTTP, requests and responses, and similar matters. While these facets of the Web Forms model allow for rapid application development and make ASP.NET more accessible to developers with a web application background, their behavior can impact your website’s behavior and performance. View state is perhaps the most important – yet most misunderstood – feature of the Web Forms model. In a nutshell, view state is a technique that automatically persists programmatic changes to the Web controls on a page.

Traditionally, developers using Web controls enjoyed increased productivity but at the cost of control over the rendered markup. For instance, many ASP.NET controls automatically wrap their content in <table> for layout or styling purposes. This behavior runs counter to the web standards that have evolved over the past several years, which favor cleaner, terser HTML; sparing use of tables; and Cascading Style Sheets (CSS) for layout and styling. Furthermore, the <table> elements and other automatically-added content makes it harder to both style the Web controls using CSS and to work with the controls from client-side script. One of the aims of ASP.NET version 4.0 is to give Web Form developers greater control over the markup rendered by Web controls. Last week’s article, Take Control Of Web Control ClientID Values in ASP.NET 4.0 , highlighted how new properties in ASP.NET 4.0 give the developer more say over how a Web control’s ID property is translated into a client-side id attribute. In addition to these ClientID -related properties, many Web controls in ASP.NET 4.0 include properties that allow the page developer to instruct the control to not emit extraneous markup, or to use an HTML element other than <table> . This article explores a number of enhancements made to the data Web controls in ASP.NET 4.0.

Each server-side Web control in an ASP.NET Web Forms application has an ID property that identifies the Web control and is name by which the Web control is accessed in the code-behind class. When rendered into HTML, the Web control turns its server-side ID value into a client-side id attribute. Ideally, there would be a one-to-one correspondence between the value of the server-side ID property and the generated client-side id , but in reality things aren’t so simple. By default, the rendered client-side id is formed by taking the Web control’s ID property and prefixed it with the ID properties of its naming containers . In short, a Web control with an ID of txtName can get rendered into an HTML element with a client-side id like ctl00_MainContent_txtName . This default translation from the server-side ID property value to the rendered client-side id attribute can introduce challenges when trying to access an HTML element via JavaScript, which is typically done by id , as the page developer building the web page and writing the JavaScript does not know what the id value of the rendered Web control will be at design time. (The client-side id value can be determined at runtime via the Web control’s ClientID property .) ASP.NET 4.0 affords page developers much greater flexibility in how Web controls render their ID property into a client-side id . This article starts with an explanation as to why and how ASP.NET translates the server-side ID value into the client-side id value and then shows how to take control of this process using ASP.NET 4.0. Read on to learn more! Read More >

As developers, we all make assumptions when programming. Perhaps the biggest assumption we make is that those libraries and tools that ship with the .NET Framework are the best way to accomplish a given task. For example, most developers assume that using ASP.NET’s Membership system is the best way to manage user accounts in a website (rather than rolling your own user account store). Similarly, creating a Web Reference to communicate with a web service generates markup that auto-creates a proxy class , which handles the low-level details of invoking the web service, serializing parameters, and so on.

Last week’s article – Dynamically Generating and Caching Images in ASP.NET with the GeneratedImage Control – looked at how to programmatically create and cache images on the fly using the GeneratedImage control, one of a suite of “Futures” technologies found in the ASP.NET Team’s CodePlex site . Programmatically creating and displaying images entails the use of an HTTP Handler for generating the binary content of the dynamically-generated image. While this HTTP Handler can be implemented as an ASP.NET page, the GeneratedImage control includes the ImageHandler class, which serves as a base class for HTTP Handlers designed specifically to generate and serve dynamic images and includes built-in functionality for caching images on the client and/or web server. Last week’s article illustrated both how to create an HTTP Handler for generating dynamic images (one that extended ImageHandler ) as well as how to use the GeneratedImage Web control to display such dynamically-generated images in a web page. In addition to its image generation and caching features, the ImageHandler class includes functionality for performing image transforms

Microsoft’s ASP.NET AJAX framework offers two models for developing interactive web applications: client-centric and server-centric. With the server-centric model, developers use the standard ASP.NET controls – the GridView, Buttons, TextBoxes, and so forth – but place them within an UpdatePanel control . The UpdatePanel control automatically converts normal postbacks to partial page postbacks and seamlessly updates the page’s display with any modifications made by server-side code. On the other hand, with the client-centric model the developer is responsible for writing the JavaScript that performs any asynchronous requests to the server, as well as the script that updates the page on response. The server-centric model is easier to use and more familiar to developers who have a solid background with ASP.NET controls, but who are not as comfortable with JavaScript and HTML. However, that ease of use comes at a cost: the server-centric model shuttles a substantial amount of data between the client and server on each partial page postback. In short, the UpdatePanel sends the page’s view state to the server on a partial page postback and receives this (perhaps modified) view state back in response, regardless of whether the view state is needed to perform the server-side logic

I started my career as a web developer with Microsoft’s Active Server Pages (ASP), the predecessor to ASP.NET. ASP was a very simple scripting engine and lacked the tools that ASP.NET developers today take for granted, most notably a debugger. Debugging an ASP script typically involved littering the code with Response.Write statements to output the values of variables at different points in time of the script’s life-cycle. Debugging an ASP.NET page is so much easier thanks to the Visual Studio debugger, which allows you to set breakpoints, step through executing code, use Watch windows to keep an eye on variable values as they change, and an Intermediate window to evaluate statements during debug time. While the Visual Studio debugger has greatly improved the debugging story, there are certain scenarios where a server-side debugger is of little or no help. In certain cases the problem is not in the server-side code but instead in what is being sent from the client to the server (or vice-a-versa).

This article is the third installment of a four-part series that examines how to build a data-driven web applications that offers dynamic user interfaces. Over the past two articles we created a sample web application that allows for numerous law firms to log in to the site and manage their clientele.

This article is the second installment of a four-part series that examines how to build a data-driven web applications that offers dynamic user interfaces. Over the course of this article series we will build a complete and functional web application with a dynamic, data-driven user interface. Specifically, the demo application is a fictional website used by numerous law firms to manage their clientele