· ASP .Net Page Compilation
Request For A Page >> Parsing Of The Page Into A DLL By Page Compiler >> DLL With Compiled Class Places Into A Temporary Directory >> Render The Page Using The Compiled Class.
The process of compilation of the page occurs only once for a .Aspx page. Every time a request is occurs for the same page, that request is satisfied by instantiating the class generated.
· ASP .Net is implemented as an HTTP handler. Different ASP .Net services (not web services) like state management, security and others, all handles by various HTTP handler/modules. Each HTTP handler is responsible for serving a specific task. To implement your own HTTP runtime handler, you can create a class that supports the HTTP runtime interface, add your extension and class to the web.config file and hence write your own web technologies. When your HTTP runtime handler is hosted in IIS, you must add your extension to the IIS configuration map.
ASP .Net uses the compilers section of the machine.config file to define the mapping of a page's extension and available languages that can be used in ASP .Net.
· ASP .Net enables you to build the following types of server controls:
1) Custom server control: You can write the server controls in a compiled form, where you develop a class that inherits from one of the ASP .Net server controls classes.
2) User controls: You can declare other ASP .Net pages as controls, and then use those pages to build up other pages.
· Overloads keyword with methods is not required when overloading methods in the same class, but if it is used, it must be used on all overloaded methods.
· Shadows means that the method in the parent class is not available, and allows creation of methods with the different signature than that of the parent. It effectively re-declares the type.
· An interface is the description of the methods and properties a class will expose – it's an immutable contract with the outside world.
· .Net's CTS also responsible for cross-language functionality.
· Page Events: Page_Init >> Page_Load >> Control_Event >>
Page_Unload
· The difference between Page_Init and Page_Load is that the controls are only guaranteed to be fully loaded in the Page_Load. The controls are accessible in the Page_Init event, but the ViewState is not loaded, so controls will have their default values, rather than any values set during the postback.
· Sample ASP .Net page format:
<%@ Import Namespace="System.Data" %>
<html>
<head>
>
runat="server"/>
</html>
· Page's IsPostBack property would be false when the page is loaded first time, and it will be true on subsequent request.
· When a client makes a request to the server for a page, the compilation process creates a class derived from System.Web.UI.Page, and includes all the components (.aspx file being requested, code file for the page, any user control used by the page). This dynamically created page class can than be instantiated to render the requested page. This compilation process is occurs only first time when any user requests the page. On any subsequent requests this compiled class can be used to render the same page again and again.
· Page class has a unique step, known as rendering step, when HTML is actually generated for the output to the client.
· When your code behind contains a class named MyClass then the .aspx page linked with the code behind file like:
<%@ PAGE Inherits="MyClass" Code="MyPage.Vb %">
· To merge a HTML file with the currently rendering page HTML use following WriteFile method of the response object into Page_Load event: Response.WriteFile("C:\Temp\Content.html")
· The ViewState contains the state of all user controls on the page. This information is stored as name-value pairs using the Sytem.Web.UI.StateBag object. The ViewState is stored as a string variable that is passed back to the client in the page. String representing ViewState values is stored as a hidden form field. We can enable or disable the ViewState by using EnableViewState property at page or control level.
· Client makes requests to server (round-trips) through an HTTP POST.
· In processing of control events, those events are process first that being happened at client but did not cause a post-back. After that the event that caused a post-back is processed.
· Any in-line script code is run at rendering stage.
· When you have an event of a control that can be handled on either the client or the server, then the server handling of that event will take precedence. For example if a button control have both server (OnServerClick) and client (OnClick) event handler than client side event handler will be ignored.
· ViewState property is a collection of the state that is maintained by the page. This option is available through a state bag object. We can use ViewState property like:
ViewState("MyName") = "John" ' Adding value
Integer Name As String
Name = ViewState("MyName") ' Retrieving value
Comments