What is ASP.net?
ASP.NET is the next generation web application framework developed and marketed by Microsoft based on .NET Framework. But not to be confused that it's not an upgraded version of ASP. It was first released in January 2002 with version 1.0 of the .NET Framework, and is the successful successor to Microsoft's Active Server Pages (ASP) technology.
ASP.NET allow programmers to build dynamic web sites, web applications ,web services and so many strong features. One of the key features of ASP.NET is that it uses an event-based programming model.
It is built on the Common Language Runtime (CLR), allowing programmers to write ASP.NET code using any supported .NET languages. It is a server side scripting technology that enables scripts (embedded in web pages) to be executed by an web server(Internet Information Services).In ASP.NET, you are not limited to scripting languages. You can now use the following .NET languages:
Using Visual Studio, the development tool from Microsoft, web developers can develop very compelling applications using ASP.NET, with the ease of drag-and-drop server controls. Latest version finally announced by Microsoft. By adopting agile practices, and using IDE and ALM tools, Microsoft have been able to complete the release in half as many milestones this time around. Developing great apps for Windows 8 is an important goal of this release.
How it works?
You should be familiar with the page life cycle process in order to correctly initialize controls. The life cycle of a control is based on the page life cycle, and the page raises many of the events that you need to handle in a custom control.
When a web browser requests a page from a web server, the web server (IIS) will first check if the request is for an HTML page. If it is, the request is fulfilled by fetching the files from the OS and then returning it to the client (web browser). If the client is requesting an ASP.NET page, IIS will pass the request to the ASP.NET runtime, which will then process the application by reads the file, line by line, and executes the scripts in the file. After process complete it returns the output to the client as an format of pure html.
When an ASP.NET page runs, the page goes through a life cycle in which it performs a series of processing steps. These include initialization, instantiating controls, restoring and maintaining state, running event handler code, and rendering. It is important for you to understand the page life cycle so that you can write code at the appropriate life-cycle stage for the effect you intend.
In order to memorize whole page life cycle process of Asp.net, keep store this word "SILVER" in your memory, which is defined as
S = Start
I = Initialization
L = Load
V = Validate
E = Event Handlers
R = Render
Before and after "SILVER" there's one step each to be processed. Each step will be completely defined as:
PAGE REQUEST:
The page request occurs before the page life cycle begins. When the page is requested by a user, ASP.NET determines whether the page needs to be parsed and compiled, or whether a cached version of the page can be sent in response without running the page.
START:
In the start stage, page properties such as Request and Response are set. At this stage, the page also determines whether the request is a postback or a new request and sets the IsPostBack property. The page also sets the UICulture property.
INITIALIZATION:
During page initialization, controls on the page are available and each control's UniqueID property is set. A master page and themes are also applied to the page if applicable. If the current request is a postback, the postback data has not yet been loaded and control property values have not been restored to the values from view state.
LOAD:
During load, if the current request is a postback, control properties are loaded with information recovered from view state and control state.
VALIDATE & EVENT HANDLING:
If the request is a postback, control event handlers are called. After that, the Validate method of all validator controls is called, which sets the IsValid property of individual validator controls and of the page. There is an exception to this sequence: the handler for the event that caused validation is called after validation.
RENDER:
Before rendering, view state is saved for the page and all controls. During the rendering stage, the page calls the Render method for each control, providing a text writer that writes its output to the OutputStream object of the page's Response property.
UNLOAD:
The Unload event is raised after the page has been fully rendered, sent to the client, and is ready to be discarded. At this point, page properties such as Response and Request are unloaded and cleanup is performed.
Within each stage of the life cycle of a page, the page raises events that you can handle to run your own code. For control events, you bind the event handler to the event, either declaratively using attributes such as onclick, or in code. Pages also support automatic event wire-up, meaning that ASP.NET looks for methods with particular names and automatically runs those methods when certain events are raised. If the AutoEventWireup attribute of the @ Page directive is set to true, page events are automatically bound to methods that use the naming convention of Page_event, such as Page_Load and Page_Init.
PreInit:
Raised after the start stage is complete and before the initialization stage begins. Use this event for the following:
-
Check the IsPostBack property to determine whether this is the first time the page is being processed. The IsCallback and IsCrossPagePostBack properties have also been set at this time.
-
Create or re-create dynamic controls.
-
Set a master page dynamically.
-
Set the Theme property dynamically.
-
Read or set profile property values.
If the request is a postback, the values of the controls have not yet been restored from view state. If you set a control property at this stage, its value might be overwritten in the next event.
Init:
Raised after all controls have been initialized and any skin settings have been applied. The Init event of individual controls occurs before the Init event of the page. Use this event to read or initialize control properties.
InitComplete:
Raised at the end of the page's initialization stage. Only one operation takes place between the Init and InitComplete events: tracking of view state changes is turned on. View state tracking enables controls to persist any values that are programmatically added to the ViewState collection. Until view state tracking is turned on, any values added to view state are lost across postbacks. Controls typically turn on view state tracking immediately after they raise their Init event. Use this event to make changes to view state that you want to make sure are persisted after the next postback.
PreLoad:
Raised after the page loads view state for itself and all controls, and after it processes postback data that is included with the Request instance.
Load:
The Page object calls the OnLoad method on the Page object, and then recursively does the same for each child control until the page and all controls are loaded. The Load event of individual controls occurs after the Load event of the page. Use the OnLoad event method to set properties in controls and to establish database connections.
Control Events:
Use these events to handle specific control events, such as a Button control's Click event or a TextBox control's TextChanged event. In a postback request, if the page contains validator controls, check the IsValid property of the Page and of individual validation controls before performing any processing.
Load Complete:
Raised at the end of the event-handling stage. Use this event for tasks that require that all other controls on the page be loaded.
PreRender:
Raised after the Page object has created all controls that are required in order to render the page, including child controls of composite controls. The Page object raises the PreRender event on the Page object, and then recursively does the same for each child control. The PreRender event of individual controls occurs after the PreRender event of the page. Use the event to make final changes to the contents of the page or its controls before the rendering stage begins.
PreRenderComplete:
Raised after each data bound control whose DataSourceID property is set calls its DataBind method.
SaveStateComplete:
Raised after view state and control state have been saved for the page and for all controls. Any changes to the page or controls at this point affect rendering, but the changes will not be retrieved on the next postback.
Render:
This is not an event; instead, at this stage of processing, the Page object calls this method on each control. All ASP.NET Web server controls have a Render method that writes out the control's markup to send to the browser. If you create a custom control, you typically override this method to output the control's markup. However, if your custom control incorporates only standard ASP.NET Web server controls and no custom markup, you do not need to override the Render method. A user control automatically incorporates rendering, so you do not need to explicitly render the control in code.
Unload:
Raised for each control and then for the page. In controls, use this event to do final cleanup for specific controls, such as closing control-specific database connections. For the page itself, use this event to do final cleanup work, such as closing open files and database connections, or finishing up logging or other request-specific tasks. During the unload stage, the page and its controls have been rendered, so you cannot make further changes to the response stream. If you attempt to call a method such as the Response.Write method, the page will throw an exception.
Individual ASP.NET server controls have their own life cycle that is similar to the page life cycle. For example, a control's Init and Load events occur during the corresponding page events. Although both Init and Load recursively occur on each control, they happen in reverse order. The Init event (and also the Unload event) for each child control occur before the corresponding event is raised for its container (bottom-up). However the Load event for a container occurs before the Load events for its child controls (top-down). Master pages behave like child controls on a page: the master page Init event occurs before the page Init and Load events, and the master page Load event occurs after the page Init and Load events.
If controls are created dynamically at run time or declaratively within templates of data-bound controls, their events are initially not synchronized with those of other controls on the page. For example, for a control that is added at run time, the Init and Load events might occur much later in the page life cycle than the same events for controls created declaratively. Therefore, from the time that they are instantiated, dynamically added controls and controls in templates raise their events one after the other until they have caught up to the event during which it was added to the Controls collection.
DataBinding:
Raised after the control's PreRender event, which occurs after the page's PreRender event. This applies to controls whose DataSourceID property is set declaratively. Otherwise the event happens when you call the control's DataBind method. This event marks the beginning of the process that binds the control to the data. Use this event to manually open database connections, if required, and to set parameter values dynamically before a query is run.
RowCreated (GridView only) or
ItemCreated (DataList, DetailsView, SiteMapPath, DataGrid, FormView, Repeater, and ListView controls) :
Raised after the control's DataBinding event. Use this event to manipulate content that is not dependent on data binding. For example, at run time, you might programmatically add formatting to a header or footer row in a GridView control.
RowDataBound (GridView only) or
ItemDataBound (DataList, SiteMapPath, DataGrid, Repeater, and ListView controls) :
Raised after the control's RowCreated or ItemCreated event. When this event occurs, data is available in the row or item, so you can format data or set the FilterExpression property on child data source controls in order to display related data within the row or item.
DataBound:
Raised at the end of data-binding operations in a data-bound control. In a GridView control, data binding is complete for all rows and any child controls. Use this event to format data-bound content or to initiate data binding in other controls that depend on values from the current control's content.
The Login control can use settings in the Web.config file to manage membership authentication automatically. However, if your application requires you to customize how the control works, or if you want to understand how Login control events relate to the page life cycle.
LoggingIn:
Raised during a postback, after the page's LoadComplete event has occurred. This event marks the beginning of the login process. Use this event for tasks that must occur prior to beginning the authentication process.
Authenticate:
Raised after the LoggingIn event. Use this event to override or enhance the default authentication behavior of a Login control.
LoggedIn:
Raised after the user name and password have been authenticated. Use this event to redirect to another page or to dynamically set the text in the control. This event does not occur if there is an error or if authentication fails.
LoginError:
Raised if authentication was not successful. Use this event to set text in the control that explains the problem or to direct the user to a different page.
