Freelance Asp.net developer-- AJAX With ASP.Net

Use of AJAX with Asp.net

Over the past few months, there's been an increasing amount of buzz about Asynchronous JavaScript and XML (AJAX) programming. It's about time. AJAX is the new term for a technology that Microsoft IE developers have been using for years—the ability to make background requests to a server from a client Web page using the XMLHttpRequest object. However, because that object was originally invented and implemented by Microsoft as an ActiveX control, developers who had to support multiple browser types eschewed the technology, despite its early promise for building more interactive and efficient Web applications.

But now that Opera, Netscape, Safari, and Firefox all include a built-in JavaScript implementation of the XMLHttpRequest object, the technology has been reinvigorated, thanks mainly to popular sites such as Google's GMail and Maps, which utilize the XMLHttpRequest object. Except for the code needed to invoke an XMLHttpRequest object on the various browsers, all the implementations are otherwise similar from a coder's point of view, exposing a common set of methods and properties, and letting you create AJAX applications that run identically across all the major browsers.

From AJAX Frameworks to Atlas

.NET developers, many of whom have already used the XMLHttpRequest object in their ASP and ASP.NET applications, began building additional support frameworks for AJAX, most notably Michael Schwarz's free AJAX.NET project. Microsoft, often slow to recognize trends, has finally recognized this one. Yesterday, Charles Fitzgerald, Microsoft's General Manager for Platform Technologies, announced "Atlas," the code name for Microsoft's upcoming AJAX support. Atlas goes far beyond the original concept, including integrated debugging with Visual Studio.

Scott Guthrie, manager of Microsoft's Web Platform and Tools Team, described Atlas' planned features in his blog:

The Atlas Client Script Framework will work on all modern browsers, and with any web server. It also won’t require any client installation at all—to use it, you can simply include references to the right script files in your page.

The Atlas Client Script Framework will include the following components:

* An extensible core framework that adds features to JavaScript such as lifetime management, inheritance, multicast event handlers, and interfaces

* A base class library for common features such as rich string manipulation, timers, and running tasks

* A UI framework for attaching dynamic behaviors to HTML in a cross-browser way

* A network stack to simplify server connectivity and access to Web services

* A set of controls for rich UI, such as auto-complete textboxes, popup panels, animation, and drag and drop

* A browser compatibility layer to address scripting behavior differences between browsers.

Guthrie also says that Microsoft will provide new ASP.NET server controls that you'll be able to use to bind client-side controls to server-side code, and promises simple and direct access to ASMX pages and Indigo services directly through the Atlas Client Script Framework.

While AJAX won't ship with Visual Studio 2005, Microsoft plans to provide it as an add-on layer to ASP.NET and will offer a preview version to developers at the PDC conference in Los Angeles in September.

Page Life Cycle in Asp.net

Life Cycle in ASP.NET

When a web page is sent to the Web Server for processing, it goes through a sequence of steps before it finally gets displayed in the Web Browser. This article discusses these series of steps and events that occur in a page life cycle in ASP.NET.

From Web Browser to IIS

When a POST request is initiated from the client side, the Web Server traps the request and it is usually routed to an .aspx web page. The request is actually routed to the HTTP Pipeline, a chain of managed objects.

After the HTTP Page handler class is identified, the ProcessRequest () method is called which eventually fires the different page events in the life cycle of a web page. The sequence of events that takes place in the life cycle of a web page in ASP.NET is:

1. Page_Init
2. LoadViewState
3. LoadPostData
4. Page_Load
5. RaisePostDataChangedEvent
6. RaisePostBackEvent
7. Page_PreRender
8. SaveViewState
9. Page_Render
10. Page_UnLoad

All these events are associated with their respective handlers and you can even override them to customize their default behaviour. The following section discusses each of these events in detail.

The Page Life Cycle Events Explained

Once the request for the web page arrives at the web server, the ASP.NET runtime determines whether the page needs to be parsed or whether a cached version of the page needs to be rendered to the requestor. Then the Request and the Response objects for the page are set and the page life cycle starts.

The Page_Init event is the first event to be triggered in the page life cycle. It is responsible for the initialization activities that are essential to create a page instance. In this phase of the page life cycle, all the server controls of the web page are initialized to their default values. However, it should be noted that the View State for a page is not available at this stage of the page life cycle and a server control of the page cannot access other server controls of the page at this phase.

You can use the Page_Init event to create or re-create the controls that need to be created or re-created dynamically. The following example illustrates how you can override the OnInit() method.

protected override void OnInit(EventArgs e)
{
if (Page != null)
{
Page.Trace.Write ("The OnInit method has been called");
base.OnInit(e);
Page.RegisterRequiresPostBack(this);
}
}

Next, the LoadViewState method is called. "The load view state stage only happens when the page has been posted back. During this stage the view state data saved from the previous page visit is loaded and recursively populated into the Page’s control hierarchy". This method restores the View State information of a web page that was last saved using the SaveViewState method. You can override the LoadViewState() method to get an idea on how the viewstate is actually restored.

The following code example illustrates how you can override the LoadViewState() method.

protected override void LoadViewState(Object viewState)
{
Page.Trace.Write ("The LoadViewState method has been called.");
if (viewState == null)
{
base.LoadViewState(viewState);
}
}

View State is a hidden field that is associated with every web page. It is responsible for maintaining the state of web pages between postbacks. It maintains a state of a page as it moves back and forth between the web browser at the client side and the web server at the server side. However, it should be noted that ViewState does not hold the controls, rather it holds the values of the form controls and their corresponding ID's that would otherwise be lost due to a post back because they do not post with the form.

After the View State for a web page is restored, the server controls in the web page are populated with posted data, i.e., the data that was posted when the web page was sent from the we browser at the client side to the web server.

The LoadPostBackData event is fired next that processes the data that was last posted to the server for all the server controls that requires the same. Note that all controls in an ASP.NET web page is identified by a unique id. The runtime now parses the controls to match their unique ids against the Name Value Collection in the View State for the control (that has its View State enabled) and updates the control with the posted data.

The next event that gets fired is the Page_Load event that typically restores the page's control values. At this phase of the page life cycle, the web page "calls the OnLoad event method on the Page, then recursively does the same for each child control, which does the same for each of its child controls until the page and all controls are loaded." Typically, you bind data to the controls of your web form in this method or call methods write code that should be executed or loaded first before any other event of the web page is triggered.
A typical example of Page_Load event is cited below.

protected override void OnLoad(EventArgs e)
{

if(!IsPostBack)
{
//Code to bind static data to the controls
}

}

You can check the IsPostBack property of the web page to avoid re-setting the server control values. But why is the IsPostBack property necessary? Well, the reason is that the Page_Load event is fired with every request to the web page. Hence, this property is used to check whether the page was submitted to itself. Further, you can create dynamic controls for your web page here.

Freelance Asp.net Developer, Freelance Asp.net Web Development

Freelance Asp.net Developer

Which web technology your site uses does not always matter.

If you have a simple (ie. ‘static’) web site with no need of a database or any program code then which technologies you are using will not really make any practical difference. Your site could be running on Windows web servers under Microsoft Internet Information Server or on Linux under Apache Web Server and the results will be just about the same. The cost will be about the same, the speed will be about the same and the reliability will be just as good in both cases.

The difference comes when you want to add a database, or a shopping cart, or send emails from your web pages, or fill in forms, or upload files, or secure part of your site for private access or do any of those things that involve adding program code to your site.

In the last couple of years the rising star for web projects has been ASP.Net from Microsoft. This has brought a major change to the way that web sites are programmed, replacing simple scripting methods wth a powerful 'framework' that can do more, do it faster and cost less because the development time is often reduced.

Some important commentators on this scene (such as the US Gartner Group) have forecast that for the foreseeable future it is unlikely that any major new web programming project will be built on any platform other then ASP.NET.

We have been a Microsoft Partner for several years and it was natural therefore that we would adopt this new technology fairly early in its evolution. As a result we have a lot of experience in .Net technology.