Sharepoint Page Life Cycle//Sharepoint Page Request V/S ASP.Net Page Request

Before we compare life cycle of both the page request lets  first understand the asp.net application life cycle.

Stages of the ASP.NET application life cycle (IIS 7.0):

Request is made for an application resource: When the integrated pipeline receives a request, the request passes through stages that are common to all requests. These stages are represented by the RequestNotification enumeration. All requests can be configured to take advantage of ASP.NET functionality, because that functionality is encapsulated in managed-code modules that have access to the request pipeline. For example, even though the .htm file-name extension is not explicitly mapped to ASP.NET, a request for an HTML page still invokes ASP.NET modules. This enables you to take advantage of ASP.NET authentication and authorization for all resources.

The unified pipeline receives the first request for the application: When the unified pipeline receives the first request for any resource in an application, an instance of the ApplicationManager class is created, which is the application domain that the request is processed in. Application domains provide isolation between applications for global variables and enable each application to be unloaded separately. In the application domain, an instance of the HostingEnvironment class is created, which provides access to information about the application, such as the name of the folder where the application is stored. During the first request, top-level items in the application are compiled if required, which includes application code in the App_Code folder.

Response objects are created for each request: After the application domain has been created and the HostingEnvironment object has been instantiated, application objects such as HttpContext, HttpRequest, and HttpResponse are created and initialized.

An HttpApplication object is assigned to the request: After all application objects have been initialized, the application is started by creating an instance of the HttpApplication class. If the application has a Global.asax file, ASP.NET instead creates an instance of the Global.asax class that is derived from the HttpApplication class. It then uses the derived class to represent the application.
Which ASP.NET modules are loaded (such as the SessionStateModule) depends on the managed-code modules that the application inherits from a parent application. It also depends on which modules are configured in the configuration section of the application's Web.config file. Modules are added or removed in the application's Web.config modules element in the system.webServer section.

The request is processed by the HttpApplication pipeline: At this stage the request are processed and various events are called like ValidateRequest, URL Mapping, BeginRequest, AuthenticateRequest and so on. You can find more info over here. The events are useful for page developers who want to run code when key request pipeline events are raised. They are also useful if you are developing a custom module and you want the module to be invoked for all requests to the pipeline. Custom modules implement the IHttpModule interface. In Integrated mode in IIS 7.0, you must register event handlers in a module's Init method.

Stages of the Sharepoint Page Request

                The stages for the SharePoint page request are handled by the IIS in similar way. Except that there are custom handlers for the every sharepoint page request.

When you create a web application in sharepoint, WSS configures the IIS website by adding an IIS application map and creating several virtual directories. Windows SharePoint Services also copies a global.asax file and web.config file to the root directory of the hosting IIS Web site.

Because every request targeting a Web application is routed through aspnet_isapi.dll, the request gets fully initialized with ASP.NET context. Furthermore, its processing behavior can be controlled by using a custom HttpApplication object and adding configuration elements to the web.config file.

First, you can see that Windows SharePoint Services configures each Web application with a custom HttpApplication object by using the SPHttpApplication class. Note that this class is deployed in the Windows SharePoint Services system assembly Microsoft.SharePoint.dll.

In addition to including a custom HttpApplication object, the Windows SharePoint Services architecture uses a custom HttpHandler(SPHttpHandler) and a custom HttpModule(SPRequestModule). These two SharePoint-specific components are integrated into the HTTP Request Pipeline for a Web application using standard entries in the web.config file.

<configuration>   <system.web>     <httpHandlers>       <remove verb="GET,HEAD,POST" path="*" />       <add verb="GET,HEAD,POST" path="*"           type="Microsoft.SharePoint.ApplicationRuntime.SPHttpHandler,..." />     </httpHandlers>     <httpModules>       <clear />       <add name="SPRequest"          type="Microsoft.SharePoint.ApplicationRuntime.SPRequestModule,..."/>       <!-- other standard ASP.NET httpModules added back in -->     </httpModules>   </system.web> </configuration>

ASP.NET 2.0 introduced a new pluggable component type known as a virtual path provider. The idea behind a virtual path provider is that it abstracts the details of where page files are stored away from the ASP.NET runtime. By creating a custom virtual path provider, a developer can write a custom component that retrieves ASP.NET file types, such as .aspx and .master files, from a remote location, such as a Microsoft SQL Server database.

The Windows SharePoint Services team created a virtual path provider named SPVirtualPathProvider that is integrated into every Web application. The SPVirtualPathProvider class is integrated into the ASP.NET request handling infrastructure by the SPRequestModule. More specifically, the SPRequestModule component contains code to register the SPVirtualPathProvider class with the ASP.NET Framework as it does its work to initialize a Web application.

- See more at: http://kalashnikovtechnoblogs.blogspot.in/2012/04/sharepoint-page-request-vs-aspnet-page.html#sthash.Ws1cIgvh.dpuf

Sharepoint Page Life Cycle

ASP.Net Page life cycle.

S � Start
I � Initialize
L � Load
V � Validate
E � Event Handling
R � Render

Sharepoint page life cycle:-

Everybody knows ASP.NET page life cycle and sharepoint also having virtual directry which has same HTTP Handler HTTP Modules so that one usually thinks that life cycle is same as ASP.NET Page Life Cycle but it's not. Here is SharePoint 2007 Page Life Cycle

User request the SharePoint Page using http

ASP.NET calls the WSS File provider

WSS file provider returns the page from File or Database

Page is parsed by SafeMode parsor if required

Returned page is complied by ASP.NET Compiler

WSS File provider collects the page layout class and complies it

ASP.NET engine adds SharePoint Context Data to the site meta data and retreives the associated master page.

Master page got compiled and responded back to the user.

Webpart page life cycle:-

OnInit – Configuration values set using WebBrowsable properties and those in web part task pane are loaded into the web part.

LoadViewState – The view state of the web part is populated over here.

CreateChildControls – All the controls specified are created and added to controls collection. When the page is being rendered for the first time the method generally occurs after the OnLoad() event. In case of

postback, it is called before the OnLoad() event. We can make use of EnsureChildControls() - It checks to see if the CreateChildControls method has yet been called, and if it has not, calls it.

OnLoad

User Generated Event – for e.g. button click on the web part.

OnPreRender – Here we can change any of the web part properties before the control output is drawn.

RenderContents – Html Output is generated.

SaveViewState - View state of the web part is serialized and saved.

Dispose

UnLoad.