In this sample chapter from "Pure ASP.Net", we'll see what web forms are, how the code is processed on the server and how client-side code can also be integrated into web forms...
Sample Chapter: Pure ASP.Net - Server-Side Code Blocks (Page 2 of 4 )
Code to be executed on the server is contained inside a set of <script> </script> tags, similar to the tags you would use to add client-side code to a Web page. In order for the page compiler to process the source code on the server, you must add a runat="server" attribute to the tag. Page logic, including the handling of events such as the Page_Load() event, is found in server-side code blocks rather than on the client side.
If the runat="server" attribute is not specified, then the tag will be passed to the client as is. This causes unpredictable results, depending on the tag in question. In the case of ASP.NET Web controls, the browser will most likely ignore the tag entirely. HTML controls will then be displayed on the client, but they will not be accessible to ViewState management or server-side validation.
Compiling ASP.NET Web Forms As mentioned in Chapter 2, "The Common Language Runtime," all source code on an ASP.NET Web form is dynamically compiled into an intermediate language and then compiled just-in-time (JIT) into native machine code. This is handled completely behind the scenes; you do not need to compile a Web form manually. Web forms are compiled for several reasons:
Compiling the code in this way dramatically reduces the server's response time and processor load. Because the server spends less time processing each request, it can process more requests. Therefore, by using the Microsoft.NET framework, you can get more "bang for the buck" from your Web servers.
You can use strongly typed languages such as C#, Visual Basic.NET, JScript.NET, and managed C++ code for Web development on a Web form itself. This forces you to use proper coding techniques and helps eliminate the use of unstructured code that mars many standard Active Server Pages (ASP) applications.
The page compiler finds many errors that might be overlooked until runtime in an interpreted language such as VBScript in ASP.
The Intermediate Language (IL) that is generated in ASP.NET is human readable. You can learn a lot about the page processor by making changes to a page and seeing how the IL is affected.
Not just the server-side code is compiled into the IL; every element of the page is compiled, including the Hypertext Markup Language (HTML). HTML is placed into a text literal control and then added to the controls collection for the page.
Consider the simple Web form example in Listing 3.1. This page displays a message, using a label Web control. The text of the label control is specified on the server side. Listing 3.2 shows the IL code generated from the code in Listing 3.1. A complete discussion of the conversion of a Web form to IL is beyond the scope of this book. However, as you can see from Listing 3.1, even a very simple Web form can translate into some relatively intimidating code.
Listing 3.2 Automatically Generated Intermediate Language Code
namespace ASP { using System; using System.Collections; using System.Collections.Specialized; using System.Configuration; using System.Text; using System.Text.RegularExpressions; using System.Web; using System.Web.Caching; using System.Web.SessionState; using System.Web.Security; using System.Web.UI; using System.Web.UI.WebControls; using System.Web.UI.HtmlControls;
public class myPage_aspx : System.Web.UI.Page, System.Web.SessionState.IRequiresSessionState {