Article
About the Author
Zak Ruvalcaba
Involved in the Web since 1995, Zak is founder of and advisor to Module Media, a full service design and development firm in San Diego. He is author of �The Ten Minute Guide to Dreamweaver 4� and �Dreamweaver MX Unleashed�, and SitePoint's own Build Your Own ASP.NET Website Using C# and VB.NET.
Build Your Own ASP.NET Website Using C# And VB.NET, Chapter 2 - ASP.NET Basics
In Chapter 1, you learned what ASP.NET is, and what it can do—you even know how to create a simple ASP.NET page. Don't worry if it seems a little bewildering right now, because, as this book progresses, you'll learn how to use ASP.NET at more advanced levels. Note that you can download these chapters in PDF format if you'd rather print them out and read them offline.
So far, you've installed the necessary software to get going and have been introduced to some very simple form processing techniques. As the next few chapters unfold, we'll introduce more advanced topics, including controls, programming techniques, and more. Before we can begin developing applications with ASP.NET, however, you'll need to understand the inner workings of a typical ASP.NET page. This will help you identify the various parts of the ASP.NET page referenced by the many examples within the book. In this chapter, we'll talk about some key mechanisms of an ASP.NET page, specifically:
- Page structure
- View state
- Namespaces
- Directives
We'll also cover two of the "built-in" languages supported by the .NET Framework: VB.NET and C#. As this section begins to unfold, we'll explore the differences, similarities, and power that the two languages provide in terms of creating ASP.NET applications.
So, what exactly makes up an ASP.NET page? The next few sections will give you an in-depth understanding of the constructs of a typical ASP.NET page.
ASP.NET Page Structure
ASP.NET pages are simply text files with the .aspx file name extension that can be placed on an IIS server equipped with ASP.NET. When a browser requests an ASP.NET page, the ASP.NET runtime (as a component of the .NET Framework's Common Language Runtime, or CLR) parses and compiles the target file into a .NET Framework class. The application logic now contained within the new class is used in conjunction with the presentational HTML elements of the ASP.NET page to display dynamic content to the user. Sounds simple, right?
An ASP.NET page consists of the following elements:
- Directives
- Code declaration blocks
- Code render blocks
- ASP.NET server controls
- Server-side comments
- Server-side include directives
- Literal text and HTML tags
It's important to remember that ASP.NET pages are just text files with an .aspx extension that are processed by the runtime to create standard HTML, based on their contents. Presentational elements within the page are contained within the <body> tag, while application logic or code can be placed inside <script> tags. Remember this pattern from the sample at the end of the previous chapter?
Figure 2.1 illustrates the various parts of that page.
Figure 2.1. All the elements of an ASP.NET page are highlighted. Everything else is literal text and HTML tags.
As you can see, this ASP.NET page contains examples of all the above components (except server-side includes) that make up an ASP.NET page. You won't often use every single element in a given page, but you should become familiar with these elements, the purpose that each serves, and how and when it's appropriate to use them.
Directives
The directives section is one of the most important parts of an ASP.NET page. Directives control how a page is compiled, specify settings when navigating between pages, aid in debugging (error-fixing), and allow you to import classes to use within your page's code. Directives start with the sequence <%@, followed by the directive name, plus any attributes and their corresponding values, then end with %>. Although there are many directives that you can use within your pages, the two most important are the Import and Page directives. We will discuss directives in greater detail later, but, for now, know that the Import and Page directives are the most useful for ASP.NET development. Looking at the sample ASP.NET page in Figure 2.1, you can see that a Page directive was used at the top of the page as shown:
<%@ Page Language="VB" %>
<%@ Page Language="C#" %>
The Page directive, in this case, specifies the language that's to be used for the application logic by setting the Language attribute appropriately. The value provided for this attribute, in quotes, specifies that we're using either VB.NET or C#. There's a whole range of different directives; we'll see a few more later in this chapter.
Unlike ASP, in ASP.NET, directives can appear anywhere on a page, but are most commonly written as the very first lines.
Code Declaration Blocks
In Chapter 3, VB.NET and C# Programming Basics we'll talk about code-behind pages and how they let us separate our application logic from an ASP.NET page's HTML presentation code. If you're not working with code-behind pages, however, code declaration blocks must be used to contain all the application logic of your ASP.NET page. This application logic defines variables, subroutines, functions, and more. In our page, we place the code inside <script> tags, like so:
<script runat="server">
Sub mySub()
' Code here
End Sub
</script>
Here, the tags enclose some VB.NET code, but it could just as easily be C# if our page language were set thus:
<script runat="server">
void mySub() {
// Code here
}
</script>
Comments in VB.NET and C# Code
Both of these code snippets contain comments—explanatory text that will be ignored by ASP.NET, but which serves to describe how the code works.
In VB.NET code, a single quote or apostrophe (') indicates that the remainder of the line is to be ignored as a comment.
In C# code, two slashes (//) does the same. C# code also lets you span a comment over multiple lines by beginning it with /* and ending it with */.
Before .NET emerged, ASP also supported such script tags using a runat="server" attribute, although they could only ever contain VBScript, and, for a variety of reasons, they failed to find favor among developers. Code declaration blocks are generally placed inside the <head> tag of your ASP.NET page. The sample ASP.NET page shown in Figure 2.1, for instance, contained the following code declaration block:
<script runat="server">
Sub Page_Load()
lblMessage.Text = "Hello World"
End Sub
</script>
Perhaps you can work out what the equivalent C# code would be:
<script runat="server">
void Page_Load() {
lblMessage.Text = "Hello World";
}
</script>
The <script runat="server"> tag accepts two other attributes, as well. You can set the language used in the block with the language attribute:
<script runat="server" language="VB">
<script runat="server" language="C#">
If you don't specify a language within the code declaration block, the ASP.NET page will use the language provided by the language attribute of the Page directive. Each page may only contain code in a single language; for instance, it is not possible to mix VB.NET and C# in the same page.
The second attribute available is src, which lets you specify an external code file to use within your ASP.NET page:
<script runat="server" language="VB" src="mycodefile.vb">
<script runat="server" language="C#" src="mycodefile.cs">
Code Render Blocks
You can use code render blocks to define inline code or inline expressions that execute when a page is rendered, and you may recognize these blocks from traditional ASP. Code within a code render block is executed immediately as it is encountered, usually when the page is loaded or rendered for the first time, and every time the page is loaded subsequently. Code within a code declaration block, on the other hand, occurring within script tags, is only executed when it is called or triggered by user or page interactions. There are two types of code render blocks: inline code and inline expressions, both of which are typically written within the body of the ASP.NET page.
Inline code render blocks execute one or more statements and are placed directly inside a page's HTML within <% and %> characters.
Inline expression render blocks can be compared to Response.Write() in classic ASP. They start with <%= and end with %>, and are used to display values of the variables and methods on a page.
Looking back at Figure 2.1, you can see both types of code render blocks:
<% Dim Title As String = "Zak Ruvalcaba" %>
<%= Title %>
This equates to the following C#:
<% String Title = "Zak Ruvalcaba"; %>
<%= Title %>
The first line represents an inline code render block and must contain complete statements in the appropriate language. Here, we're setting the value of the Title variable to the string Zak Ruvalcaba. The last line is an example of an inline expression render block used to write out the value of the Title variable, Zak Ruvalcaba, onto the page.
ASP.NET Server Controls
At the heart of ASP.NET pages lies the server controls, which represent dynamic elements that your users can interact with. There are four basic types of server control: ASP.NET controls, HTML controls, validation controls, and user controls.
All ASP.NET controls must reside within a <form runat="server"> tag in order to function correctly. The only two exceptions to this rule are the HtmlGenericControl and the Label Web control.
Server controls offer the following advantages to ASP.NET developers:
- We can access HTML elements easily from within our code: we can change their characteristics, check their values, or even dynamically update them straight from our server-side programming language of choice.
- ASP.NET controls retain their properties even after the page has been processed. This process is known as view state. We'll be covering view state later in this chapter. For now, just know that view state prevents the user from losing data that has already been entered into a form once it's been sent to the server for processing. When the response comes back to the client's browser, text box values, drop-down list selections, etc., are all retained through view state.
- With ASP.NET controls, developers are able to separate the presentational elements (everything the user sees) and application logic (dynamic portions of the ASP.NET page) of a page so that each can be considered separately.
Because ASP.NET is all about controls, we'll be discussing them in greater detail as we move through this book. For instance, in the next few chapters, we'll discuss HTML controls and Web controls (Chapter 4, Web Forms and Web Controls), Validation controls (Chapter 5, Validation Controls), Data controls (Chapter 9, The DataGrid and DataList Controls), and so on.
Server-Side Comments
Server-side comments allow you to include, within the page, comments or notes that will not be processed by ASP.NET. Traditional HTML uses the <!-- and --> character sequences to delimit comments; anything found within these will not be displayed to the user by the browser. ASP.NET comments look very similar, but use the sequences <%-- and --%>.
Our ASP.NET example contains the following server-side comment block:
<%-- Declare the title as string and set it --%>
The difference between ASP.NET comments and HTML comments is that ASP.NET comments are not sent to the client at all. Don't use HTML comments to try and comment out ASP.NET code. Consider the following example:
<!--
<button runat="server" id="myButton" onServerClick="Click">Click
Me</button>
<% Title = "New Title" %>
-->
Here, it looks as if a developer has attempted to use an HTML comment to hide not only an HTML button control, but a code render block as well. Unfortunately, HTML comments will only hide things from the browser, not the ASP.NET runtime. So, in this case, while we won't see anything in the browser that represents these two lines, they will, in fact, have been processed by ASP.NET, and the value of the variable Title will be changed to New Title. The code could be modified to use server-side comments very simply:
<%--
<button runat="server" id="myButton" onServerClick="Click">Click
Me</button>
<% Title = "New Title" %>
--%>
Now, the ASP.NET runtime will ignore the contents of this comment, and the value of the Title variable will not be changed.