The Page Life Cycle of Client [Browser]

Introduction

This article explains the Client Life Cycle of Ajax Script Manager and Update Control. It also explains the page life cycle when a partial postback happens because of Ajax control, and the control over the events as a devoloper.

The Page Life Cycle of Client [Browser]

We all know the normal ASP.NET page life cycle events. The Ajax controls will have more events added to those existing. The events are more related to the client side rather than the server side. The normal page events happen at the server side and these Ajax events occur in the client side. I am not going to discuss more about the server page events, we will look at the page events of the client side.

Sys.Application Class

The events are related to the Sys.Application class, which provides a runtime object to take care of client events and to manage client components. This object provides access to all its members without creating an instance for it.

• pageInit
• pageLoad
• pageUnload

pageInit

pageInit event occurs only once for the first time when the page is loaded, and for every normal post back. This event will not be called when the postback happens to be partial using update panel or by any other Ajax method. It occurs after the server Page Render event. Also after all the script related to the ScriptManager is loaded, but before the object or controls created in the client client. If we are creating any components on the client side, this is a good place to write our first time intialization code. We can have a hold for this event by adding a function handler to pageInit event. By simply adding the handler, our function will be called after the init event. Since the page is not loaded, we cannot have a reference to any object or control in the page. We can add any number of handlers to these events. Also we can remove existing handlers. The syntax looks like this:

Sys.Application.add_init(MyInit);
//Sys.Application.remove_init(MyInit);

function MyInit()
{
    alert("MyInit added to page init");
}

pageLoad

pageLoad event occurs after client pageInit event. After pageInit event, all the objects or controls are created after that pageload will be called. It occurs every time the page is loaded for both normal and partial renders. We can refer any object here in the event, after this event the page is served to the user. Similarly as pageInit event, pageLoad event will also accept handlers to be added after this event. The syntax is almost similar, looks like this:

Sys.Application.add_load(MyLoad);
//Sys.Application.remove_load(MyLoad);

function MyLoad()
{
    alert("MyLoad added to page load");
}

pageUnload

pageUnload event occurs only once when page is redirected to another page, or when the browser window is closed. The redirection has to happen in normal postback or using Response.Redirect method, if we try to redirect using Server.Transfer, where the client will not be aware of the page redirection, it throws an client exception named PageRequestManagerParserErrorException. This event is not linked with server Page Unload event, which occurs after Page Render in server side, has nothing to do with client side. By the time all controls will be loaded into the browser[client]. pageUnload event will accept handlers to be added after this event. The syntax looks like this:

Sys.Application.add_unload(MyUnload);
//Sys.Application.remove_unload(MyUnload);

function MyUnload()
{
    alert("MyUnload added to page unload");
}

Additional Information

The event handlers and other code should be written is a separate js file and that should be specified under scripts section of ScriptManger control. Here the js file named "UsingJScript.js" is attached to ScriptManger control as shown below:

<asp:ScriptManager ID="ScriptManager1" runat="server" EnablePartialRendering="true">
    <Scripts>
        <asp:ScriptReference Path="UsingJScript.js" />
    </Scripts>
</asp:ScriptManager>

Sys.WebForms.PageRequestManager Class

This class is responsible for partial post back. This object will be initiated on its own, to get this object in client side, the page should have a ScriptManager and minimum one UpdatePanel. This object also has certain events which will be involved in the client page life cycle. The full name of the class along with the namespace is Sys.WebForms.PageRequestManager. Let us see the events related to this:

• initializeRequest
• beginRequest
• pageLoading
• pageLoaded
• endRequest

initializeRequest

intializeRequest event will be triggered after the control is triggered for the asynchronous partial postback by the user. This prepares the request which has to be sent to the server to get the response. The partial postback can be aborted or cancelled at this stage. we can add our handlers to this event as any other life cycle event. Our handlers will be called after the intialRequest is called. The intializeRequestEventArgs gives more details about the event, we get the reference of this class as an argument of event. The code snippet is shown below:

//This statement should be inside pageInit or pageLoad event.
//adds the handler MyIntializeRequest to the intializeRequest event
Sys.WebForms.PageRequestManager.getInstance().add_initializeRequest(MyIntializeRequest);

//removes the handler MyIntializeRequest from the intializeRequest event
//Sys.WebForms.PageRequestManager.getInstance().remove_initializeRequest
//(MyIntializeRequest);

function MyIntializeRequest(sender,args)
{
    alert("My Request is getting initalized");
}

beginRequest

beginRequest is triggered after the intializeRequest, also before the asynchronous postback is processed. This takes care of sending the request to the server. We can add our handlers to this event. The handlers are called first before the request is posted to the server. The beginRequestEventArgs gives more details about the event and other objects related to this. Normally this event will be used to display a graphic or any message to keep the user interactive, till the request gets processed in the server. After this particular event, the server takes charge of processing the request. The code snippet is given below:

//This statement should be inside pageInit or pageLoad event.
//adds the handler MyBeginRequest to the beginRequest event
Sys.WebForms.PageRequestManager.getInstance().add_beginRequest(MyBeginRequest);

//removes the handler MyBeginRequest from the beginRequest event
//Sys.WebForms.PageRequestManager.getInstance().remove_beginRequest(MyBeginRequest);

function MyBeginRequest(sender,args)
{
    alert("My Request is ready about to sent to server");
}

pageLoading

pageLoading is the first event called after the server process finished, which means after page render event of server. When it is called, the client is not loaded with the new response and it is in hold of the response object. We can have a reference of it here for any manipulations. Also it gives reference to the panels which are going to get modified after this partial postback. If we require any animation or transition to happen before the updated data is placed in the respective position, the pageLoadingEventArgs gives more details about the events and other objects related to this. Normally we will do some control manipulation in this part before it is getting loaded in the page. The code snippet is given below:

//This statement should be inside pageInit or pageLoad event.
//adds the handler MyPageLoading to the pageLoading event
Sys.WebForms.PageRequestManager.getInstance().add_pageLoading(MyPageLoading);

//removes the handler MyPageLoading from the pageLoading event
//Sys.WebForms.PageRequestManager.getInstance().remove_pageLoading(MyPageLoading);

function MyPageLoading(sender, args)
{
    alert("My page is started loading");
}

pageLoaded

pageLoaded is event triggered after all the contents of the page are updated due to synchronous or asynchronous postback. We can clear the graphic or animation which we initiated in the beginRequest event here. We get the reference of the response and other object and controls related to the postback using the class pageLoadedEventArgs. We can also do an animation or trasition here instead of pageLoading event. The code snippet is below:

//This statement should be inside pageInit or pageLoad event.
//adds the handler MyPageLoaded to the pageLoaded event
Sys.WebForms.PageRequestManager.getInstance().add_pageLoaded(MyPageLoaded);

//removes the handler MyPageLoaded from the pageLoaded event
//Sys.WebForms.PageRequestManager.getInstance().remove_pageLoaded(MyPageLoaded);

function MyPageLoaded(sender, args)
{
    alert("My page is loaded");
}

endRequest

endRequest event will be the last event to be triggered in the client postback cycle. After this, the control is given back to the user. This event can be used to notify the status of request to the user. This event can be used to log errors. As a finally in the try catch block, this event will be called irrespective of whether the postback succeeded or failed. The objects and other data related to this can be referred using the endRequestEventArgs class. The code snippet is shown below:

//This statement should be inside pageInit or pageLoad event.
//adds the handler MyEndRequest to the endRequest event
Sys.WebForms.PageRequestManager.getInstance().add_endRequest(MyEndRequest);

//removes the handler MyEndRequest from the endRequest event
Sys.WebForms.PageRequestManager.getInstance().remove_endRequest(MyEndRequest);

function MyEndRequest(sender, args)
{
    alert("My Request has end");
}

Additional Information

We can refer this object inside the client pageInit or in pageLoad event. We cannot get the reference of this at the first time, only after the script is loaded. We can have a hold on the object or will get the reference of the object. The normal way to add code related to this will happen inside pageInit or pageLoad events. The error handling should be done at the endRequest event. If any error occurs, then we will get a reference of the error in this event args. When a server throws an error, the pageLoading and pageLoaded event were skipped and directly this event will be triggered. We will discuss these issues and the respective Args Class of each event in the next article.