PAGE

    -::PAGE::-
In general, the life cycle for a Web Forms page is similar to that of any Web process that runs on the server. Certain characteristics of Web processing — information passed via HTTP protocol, the stateless nature of Web pages, and so on — apply to Web Forms pages just as they do to most Web applications.
The ASP.NET page framework performs many Web application services for you. For example, the ASP.NET page framework captures information posted with the Web Forms page, extracts the relevant values, and makes the information accessible via object properties.
Querry?? What is RoundTrip?
For Each user action on the form, the form must be posted to the server, processed, and returned to the browser. This sequence of events is referred to as a round trip.
In Web Forms, most user actions — such as clicking a button — result in a round trip.
In any Web scenario, pages are recreated with every round trip.
For that reason, the events available in ASP.NET server controls are usually limited to click-type events.
By the same token, server controls do not expose high-frequency events such as onmouseover, because each time such an event is raised, another round trip to the server would occur, which would considerably affect response time in the form.
Querry?? Why pages are said to be stateless?
The values of a page's variables and controls are not preserved on the server.
In a traditional Web application, the only information that the server has about a form is the information that the user has added to the controls on the form, because that information is sent to the server when the form is posted. Other information, such as variable values and property settings, is discarded.
ASP.NET works around these limitations in the following ways:
• It saves page and control properties between round trips. This is referred to as saving the view state of the control.
• It provides state management facilities so you can save your own variable and application-specific or session-specific information between round trips.
• It can detect when a form is requested for the first time versus when the form is posted, which allows you to program accordingly. You may want a different behavior during a page postback versus an initial request.

Querry??  Benefits of an Event-Driven Model versus a Linear Processing Model
If you have experience using Active Server Pages (ASP), you recognize that ASP is a linear processing model. An ASP page is processed in a top-to-bottom sequence. Each line of ASP code and static HTML is processed in sequence as it appears in the file. User actions cause the page to be posted to the server in a round trip. Since this action causes a round trip, the server must recreate the page. After the page is recreated, it is processed in the same top-to-bottom sequence as before, and therefore the page is not exhibiting truly event-driven behavior. To create an event-driven experience, you need to explicitly design it. In addition, you have to explicitly maintain page and control state at the most basic level. This model limits the richness of the user interfaces that can be assembled, and it increases the complexity of the code needed to support it.
In comparison, an event-driven model, as in a traditional Visual Basic application, contains programmable elements that are initialized and displayed on the form. Users interact with the elements, which cause events to be raised that in turn call event handlers. This model supports true event-driven behavior, which, by design, greatly extends the richness of the user interfaces that can be assembled, and it reduces the complexity of the code needed to support it.
ASP.NET replaces the linear processing model of ASP by emulating the behavior of an event-driven model. The ASP.NET page framework is provided to implicitly make the associations of an event to an event handler for you. Using the page framework allows you to easily create a user interface that reacts to user actions. For details on creating and using events and event handlers, see Server Event Handling in Web Forms Pages.
In addition, this same framework eases the implementation of page and control state management. For more information on state management, see Web Forms State Management.
For example, ASP.NET allows you to set up event handlers in server code for events that are passed from the browser. Assume the user is interacting with a Web Forms page that contains one button server control. The user clicks the button control and an event is raised that is transmitted via an HTTP post to the server where the ASP.NET page framework interprets the posted information and associates the raised event with an appropriate event handler. This event handler can be a default handler supplied by ASP.NET or it can be your custom implementation. The framework automatically calls the appropriate event handler for the button as part of the framework's normal processing. As a result, you no longer need to explicitly design event-like behavior into a linear processing model. For more information on Web Forms event handling, see ASP.NET Server Control Event Model
Querry?? What are the different Stages in Page Processing?
The first time that an ASP.NET Web form page is executed, the code contained within the page(and any code-behind class associated with the page) is compiled into a class that inherits from the Page base class. Once compiled, the class is executed , the resulting HTML is rendered to the browser and the class is removed from memory.
During this the Web Forms Page goes through different stages. They are
1.Init:-Page and Control settings are Initialized as necessary for the request.
2.LoadViewState:-Server control state that was saved to ViewState in an earlier request is restored.
3.LoadPostData:-Any data returned in Server Control form fields is processed and the relevant Control Properties are updated.
4.Load:-Controls are Created and Loaded, and Control state matches the data entered by the client.
5.RaisePostDataChanged Event:-Events are raised in response to changes in control data from previous request to current request.
6.RaisePostBackEvent:-The event that caused the Post Back is handled and the appropriate Server-side events are raised.
7.PreRender:-Any Changes that need to be made prior to Rendering the page are processed. Any Processing after this point will not be rendered to the page.
8.SaveViewState:-Server Control State is Saved back to the Page’s View State prior to tearing down the controls.
9.Render:-Control and Page Output is rendered to the client.
(Dispose Stage:- in which References to Expensive resources such as database connections must be released in this phase. Here Dispose Method is used)
10.Unload:-The Page and its Constituent Controls are removed from memory on the server.
?Of These Stages in which stages we can handle Events?
Of These Stages you can add Page Level Event Handler for Init, Load, Pre Render and Render Stages.
For other Stages such as, LoadViewState, SaveViewState ,LoadPostData ,RaisePostDataChangedEvent,RaisePostBackEvent Stages you can override the appropriate method to customize the processing of these stages.
Querry?? What is PostBack?
Post Back is the process by which a Web Form Page submits an Http Post Request to itself in response to some User action.
Querry?? How do u handle PostBack?
LoadPostData and RaisePostDataChangedEvent are methods of the IPostBackDataHandler interface, and RaisePostBackEvent belongs to the IPostBackEventHandler interface. If your control participates in postback data processing you must implement IPostBackDataHandler. If your control receives postback events you must implement IPostBackEventHandler.
NB:-The CreateChildControls method is not listed in the table because it is called whenever the ASP.NET page framework needs to create the controls tree and this method call is not limited to a specific phase in a control's lifecycle. For example, CreateChildControls can be invoked when loading a page, during data binding, or during rendering.