Join Dotnetcodes is online Discussion Forum for Software professionals . It lets you find friends around the world and Create professional network that share similar interests as you. Get help on ur projects by industry specialists. Also get answers to all ur technical/placement related querries.Get an edge over others.
Already MemberClick here to login MVC Interview Questions Answers Interview Questions
Serial Number in SSRS Articles
Get Started Developing for Android Apps with Eclipse Articles
How to Print a Crystal Report direct to printer Articles
Razor View Engine Interview Questions Answers Interview Questions
.Net framework 4.0 Interview Questions Answers Interview Questions
SQL server reporting services Interview Questions (SSRS) part 1 Articles
Whats New in ASP.NET 4.0 Part 2 Articles
Difference between Encapsulation and Abstraction Interview Questions
Explaining SDLC -System Development Life Cycle Articles
SPIRE PDF Library Articles
Infosys Interview Questions Interview Questions
Html5 interview questions and answers Interview Questions
Dynamic Menu using HTML List Tag and CSS in ASP.Net Articles
SharePoint 2010 interview Questions Answers Interview Questions
Submit Articles | More Articles..

Whats New in ASP.NET 4.0 Part 2

Posted By: admin On:6/11/2010 8:05:12 AM in:Articles Category:ASP.NET Hits:12183
In this article, Ill take a look at whats new and improved in the Web Forms model. In future columns, Ill address the Dynamic Data control platform as a whole and explore in-depth the developments in the ASP.NET AJAX environment.


In this article we learn more about ASP.Net 4.0. In Previous article Whats New in ASP.NET 4.0 Part 1
we learn about new feature on Viewstate and Auto-Generated IDs.

HTML Enhancements

In the beginning, ASP.NET didn't offer much programmatic control over all possible tags of a Web page. For a long time, the title of a page missed an ad hoc property on the Page class. The same could be said for other popular features, like CSS files.

In ASP.NET 4.0, the Page class exposes two new string properties to let you set some common tags in the <head> 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: 

<%@ Page Language="C#"
Keywords="ASP.NET, AJAX, 4.0"
Description="ASP.NET 4.0 Web Forms" %>
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.

View Controls Refinements

Most data-bound controls offer the ability to select a given displayed element -- mostly a row. In previous versions of ASP.NET, the selection was stored as the index of the selected item within the page. This means that for pageable controls (such as the GridView control), the same selection made on, say, page one is retained on page two unless you programmatically reset the selection during the page/changing event.

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.

In addition, the FormView and ListView controls offer a little better control over their generated HTML markup. In particular, the FormView now accounts for a brand new RenderTable Boolean property. If you set it to false (the default is true), then no extra HTML table tags will be emitted and the overall markup will be easier to style via CSS. The ListView no longer needs a layout template in ASP.NET 4.0:

<asp:ListView ID="ListView1" runat="server">
<% Eval("CompanyName")%>
<hr />

The preceding code snippet is sufficient to repeat the content of the CompanyName column for each element in the data source.

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. The functionality of some ASP.NET core services, including session state, membership and role management, were abstracted to a sort of service contract so that different implementations of a given service could be used interchangeably and administrators could indicate the one they wanted from the configuration file.

For example, under the hood of the old faithful Session object, there's an instance of the HttpSessionState class whose content is retrieved by the selected session state provider. The default session state provider gets data from the in-process memory (specifically, from a slot within the Cache dictionary), but additional providers exist to store data in databases and external host processes.

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. Why should you regenerate the same page a hundred times per second? Since ASP.NET 1.0, output caching allows you to cache page responses so that following requests can be satisfied returning the cached output instead of executing the page. Figure 3 shows the sequence of application events, including the step where the system attempts to resolve the request looking into the output cache.

Up until now, any page output (which can be grouped by form and query string parameters, requesting URL, or custom strings) is stored in memory in a private area of the ASP.NET Cache. In the long run, the amount of the output cache puts additional pressure on the Web server machine by consuming memory and generating frequent updates on the Cache object. In ASP.NET 4.0, the output caching subsystem fully supports the provider model, thus giving developers the opportunity of storing page responses outside the ASP.NET worker process.A custom output cache provider is a class that derives from OutputCacheProvider. The name of the class must be registered in the configuration file, as shown below:

<outputCache defaultProvider="AspNetInternalProvider">
<add name="DiskCacheProvider"
type="Samples.DiskCacheProvider, MyProvider"/>
As usual, you can have multiple providers registered and select the default one via the defaultProvider attribute on the outputCache node. The default behavior is offered through the AspNetInternalProvider object that turns out to be the default provider, if you don't change anything in the configuration file.

The output cache provider doesn't have to be the same for all pages. You can choose a different provider on a per-request basis or even for a particular user control, page, or combination of parameters for a page. You can specify the provider name in the @OutputCache directive wherever this directive (page and/or user controls) is accepted:

<% @OutputCache Duration="3600"
providerName="DiskCache" %>

To change the provider on a per-request basis, instead, you need to override a new method in global.asax, as shown below:

// Decide which provider to use looking at the request
string providerName = ...;
return providerName;

Starting with version 2.0, session state can be stored outside the memory of the worker process. This means that any data stored in the Session object must be serialized to and from an out-of-process environment. If you look back at Figure 3, session state is loaded into the Session object around the AcquireRequestState application event. The in-memory content is then serialized back to storage at the end of the request processing.
ASP.NET 4.0 enables developers to request some compression to be applied to the data stream being sent in and out of the session provider (see Figure 4). Compression is obtained by using the GZipStream class instead of a plain Stream class to do any serialization:

<sessionState mode="SqlServer" compressionEnabled="true" ... />

To enable compression, you simply add the compressionEnabled attribute to the sessionState section of the configuration file. By default, compression is not enabled.

Any JavaScript library is made up of myriad specific JavaScript files with a more or less sophisticated graph of interconnections. ASP.NET AJAX, instead, always tried to abstract JavaScript details away from developers and offered a rather monolithic client JavaScript library, via the ScriptManager control. This will change in ASP.NET 4.0. The Microsoft AJAX client library has been refactored and split into the individual files listed in Figure 5Figure 6 shows the dependencies between individual script files in the overall library.

Figure  Split Script Files in the Microsoft AJAX Library for ASP.NET 4.0

FileGoalMicrosoftAjaxCore.jsCore functionalities of the libraryMicrosoftComponentModel.jsBase classes for the client-side object modelMicrosoftAjaxSerialization.jsJSON serializationMicrosoftAjaxGlobalization.jsData and funtions for globalizationMicrosoftAjaxHistory.jsHistory points and the client API for history managementMicrosoftAjaxNetwork.jsRaw AJAX and HTTP functionalitiesMicrosoftAjaxWebServices.jsWrapper client API for invoking servicesMicrosoftAjaxApplicationServices.jsWrapper client API for predefined ASP.NET services such as authenticationMicrosoftAjaxTemplates.jsClient-side rendering API for ASP.NET AJAX 4.0MicrosoftAjaxAdoNet.jsWrapper client API for ADO.NET services in ASP.NET AJAX 4.0
comments powered by Disqus
User Profile
Dotnetcodes Webmaster
Delhi , India
Email :You must Log In to access the contact details.
Latest Post from :admin
Infosys Interview Questions
View: 10416 | Submitted on: 7/28/2010 5:40:27 AM
Creating Excel file in C#
View: 3915 | Submitted on: 7/13/2010 5:52:53 AM
common Interview Question
View: 3459 | Submitted on: 6/14/2010 2:07:49 AM
Whats New in ASP.NET 4.0 Part 2
View: 12183 | Submitted on: 6/11/2010 8:05:12 AM
Submit Articles | All Post of This User..

All rights reserved to dotnetcodes. Logos, company names used here if any are only for reference purposes and they may be respective owner's right or trademarks.
Best viewed at 1024 x 768 resolution with Internet Explorer 5.0 or Mozila Firefox 3.5 or Google Crome and higher