The upcoming ASP.NET 4.0 platform has the same foundation as the latest 3.5 SP1 version, but it provides further refinement in the areas of Web Forms, Dynamic Data controls and, last but not least, ASP.NET AJAX
ASP.NET 4.0 has a good number of small-scale changes that together provide developers with much more control of certain frequently used features of the existing framework.
Some of the Changes are as follows :
1) More Control over Viewstate :
The viewstate is a fundamental piece of the ASP.NET Web Forms architecture, and dropping it entirely from the platform in the name of a performance gain is arguably not the best option. Years of experience has proved that a more sustainable option is having the viewstate disabled by default on the page. Even better than that is the change coming up with ASP.NET 4.0: enabling viewstate control over individual controls.
Only a few of the controls in ASP.NET pages really need viewstate. For example, all text boxes you use to simply gather text don’t need viewstate at all. If Text is the only property you use on the control, then the value of the Text property would be preserved by cross-page postbacks because of posted values.
Up until ASP.NET 4.0, turning off the viewstate for individual controls was problematic.
In ASP.NET 4.0, the System.Web.UI.Control class exposes a new property named ViewStateMode which can have the following values :
Inherit : Inherits the value of Viewstate mode from the Parent Control
Enabled : Enables viewstate for this control even if the parent control has viewstate disabled .
Disabled : Disables viewstate for this control even if the parent control has viewstate enabled .
2) More Control over Auto- Generated ID’s :
In Asp.net every control on the Page ahs an unique ID. In case of Databound Templated Controls the IDs are autogenerated, basically a concatenation of the all the IDs of the Parent Controls , its ID and a numeric Index. somethign like this :
ctl00$ContentPlaceHolder1$GridView11$TextBox1
This not only makes the download size of the page more but also makes the client scripting difficult .
ASP.NET 4.0 supports more control over the algorithm that generates the client ID of a server control.
In Asp.net 4.0 the databound Controls have the Properties “ClientIDMode” which can be specified to be Predictable and at the same time we can specify “RowClientIDSuffix” to be some Primary Key like “CustomerID”.
In this case the ID of the row will be of this format
Panel1_GridView1_ALFKI_1
Much more predictable …..
3) View Controls Refinements :
In Previous versions of ASP.NET the selection in case of databound controls was stored only as an index of the selecteditem within a Page .so if you move to next page same selection is retained unless programmatically its changed .
In ASP.NET 4.0, the current selection on a data-bound control is tracked via the value on the data key field you indicate through the DataKeyNames property. To enable this feature, you use the new PersistSelection Boolean property and set it to true. The default value is false for compatibility reasons.
4) HTML Enhancements :
In ASP.NET 4.0, the Page class exposes two new string properties to let you set some common tags in the section of a page. The two new properties are Keywords and Description. The content of these server properties will replace any content you may have indicated for the metatags as HTML literals.
The Keywords and Description properties can also be set directly as attributes of the @Page directive, as in the following example:
In ASP.NET, when you invoke Response.Redirect, you return the browser an HTTP 302 code, which means that the requested content is now available from another (specified) location. Based on that, the browser makes a second request to the specified address, and that’s it. A search engine that visits your page, however, takes the HTTP 302 code literally. This is the actual meaning of the HTTP 302 status code in that the requested page has been temporarily moved to a new address. As a result, search engines don’t update their internal tables and when the user clicks to see your page, the engine returns the original address. Next, the browser gets an HTTP 302 code and makes a second request to finally display the desired page.
To smooth the whole process, in ASP.NET 4.0 you can leverage a brand new redirect method, called RedirectPermanent. You use the method in the same way you use the classic Response.Redirect, except that this time, the caller receives an HTTP 301 status code. Code 301 actually means that the requested content has been permanently moved. For the browser, it makes no big difference, but it is a key difference for search engines.
Search engines know how to process an HTTP 301 code and use that information to update the page URL reference. Next time they display search results that involve the page, the linked URL is the new one. In this way, users can get to the page quickly and save themselves a second round-trip.
5) More Control over Output Caching :
In ASP.NET 2.0, several key parts of the ASP.NET runtime were refactored and made much more flexible and configurable. This was achieved through the introduction of the provider model.
In ASP.NET 4.0, the provider model covers another extremely important feature of ASP.NET that for some reason was left behind in previous versions: the output caching.
There are many situations where it is acceptable for a page response to be a little stale if this brings significant performance advantages. Think of an e-commerce application and its set of pages for a products catalog, for example. These pages are relatively expensive to create because they could require one or more database calls and likely some form of data join. Product pages tend to remain the same for weeks and are rarely updated more than once per day.
There are many situations where it is acceptable for a page response to be a little stale if this brings significant performance advantages. Think of an e-commerce application and its set of pages for a products catalog, for example. These pages are relatively expensive to create because they could require one or more database calls and likely some form of data join. Product pages tend to remain the same for weeks and are rarely updated more than once per day.
As usual, you can have multiple providers registered and select the default one via the defaultProvider attribute on the outputCache node.
Filed under: Latest Technologies
