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.

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 >

Want insight into the design and development of C#?  Then check out these blogs by key members of the Microsoft C# development team: C# Compiler Team Matt Warren Matt Warren is a member of the Visual C# compiler team, recently acquired from the SQL Server team.  Matt’s blog entries are a

Virtually every ASP.NET developer has, at one point or another, created a page with a Button control that, when clicked, redirects the user to some other page, perhaps sending along a value entered by the user through the querystring. The typical pattern for implementing such behavior is to add a Button to the page and create a Click event handler that executes a Response.Redirect( url ) . If the redirect incorporates some input from the user, then this pattern is expanded to include the addition of a TextBox or some other control to the page and a Response.Redirect( url ) statement that includes this control’s value. While this approach certainly works, it’s not without a couple of flaws. Firstly, this approach involves a needless round-trip to the server: clicking the Button causes the browser to re-request the page and the response from the server is simply, “Please go to url .” Ideally, when the Button was clicked the browser would immediately request the final destination URL rather than have to do a postback to find out the final destination URL. Second, this approach can lead to a confusing user experience in scenarios where there are multiple TextBoxes on the page and multiple Buttons because there may not be the expected correspondence between hitting Enter in a TextBox and having the associated Button control “clicked.” Consider a website with a master page that has a TextBox and Button for searching the site.

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