# Basic Page Structure

Besides the similarity that an ASP.NET page has with a standard HTML page you will notice a few extra features. The first of these is the first line of the page, which includes a "page directive" with three attributes:
If the page were coded in C#, the page directive would take this form:
Page directives are used to specify settings that affect the entire ASP.NET page. ASP.NET pages can be written in many different languages, so we must specify which is used for this page. The debug attribute tells the IIS webserver (or any other webserver capable of understanding it) to print debug information after the bottom of our page. The trace attribute tells IIS to print more detailed information about the execution of the page, including tracing variables. Page directives are included using special delimiters:
The next thing you'll notice that sets this page apart from a regular HTML-based page is the script block immediately following the page directive:
While script blocks themselves are not uncommon in web pages, this one is unusual because it contains the attribute runat="server". This attribute is specific to ASP.NET and indicates that this script block will contain server-side code. Within the script block, we see a few examples of Visual Basic .NET (VB.NET) code structures. The first is a comment. Comments in Visual Basic are prefixed by an apostrophe. Everything following the apostrophe will be ignored:
VB.NET
C#
There is no multi-line comment delimiter in VB.NET. Each comment line must be prefixed with an apostrophe:
VB.NET
C#
Beneath the first comment, we see the Page_Load method:
Methods (also known as "subroutines", "subs", or "functions") are named blocks of code that can be executed by calling their name.
* Subroutine - encapsulates code, but returns no value to the upstream caller.
* Function - encapsulates code, can return a value to the upstream caller.
The Page_Load method is a special method that executes whenever the page is loaded in a browser. Because this method is executed every time the page is loaded, it is a useful place to define variables and start many processes. Within the Page_Load subroutine, we can see a VB.NET If/Then structure:
In C#, it looks like this:
This conditional statement tests to see if the page is a "postback" page. We will discuss the postback mechanism in more detail later. For the time being, know that nothing in this block will execute the first time the page is loaded. But it will execute if a submit button on the page has been pressed.
Finally the script block concludes. Notice that all the code we've discussed so far happens before the opening HTML tag of the page. All of this code will be executed on the server before any of the page output is sent to the browser.
The only thing out of the ordinary in the body of the page is the form tag. Form tags are common in HTML, but this one contains the same runat="server" attribute that we saw in the script tag. This should be an indication to you that this tag, too, has a special significance in ASP.NET

# Defining & Displaying Variables

Here's a fully functional ASP.NET page in both VB.NET and C#. It demonstrates a few concepts that we will discuss below: variable declaration, variable assignment, outputting variables, and using CSS to format output. Here it is in VB.NET:
And the same page in C#:
Save this page on your server as variable_test.aspx and load it in your browser. You should see the following displayed:
That's a lot of code to print out two words, but it demonstrates some useful concepts. So let's take a closer look at it by examining each part separately. We'll begin with the Page_Load subroutine (or void method, in C# jargon). Three important things happen in that block. First we declare two variables. In VB.NET:
And in C#:
In VB.NET the keyword "Dim" is short for "Dimension." Using it indicates that we want to define the dimensions of a variable, which means we want to create a name for a variable and define its type. In C# we have to precede the name of the variable it's "type" (in our case - "string"), nothing else is needed (and don't forget semicolon at the end of the line). Our first variable is "strCarMake." Since we want to store text in this variable, we define it as a string (literally, a string of characters). We do the same for strCarModel. In both cases, we've chosen to prefix the variable name with a three-letter prefix indicating its type. So, when we see strCarMake in our code, we know that strCarMake should contain a string. This is a handy practice, but is not required (in C# it is, of course).
Declaring a variable means that memory is set aside for it and a name is associated with it so we can easily reference it later. But we still haven't put anything into our variables. In the next few lines we assign values to them. In VB.NET:
And in C#:
The equals sign is, here as in most programming languages, known as the "assignment operator." So, until we say differently, strCarMake will contain the string "Mini" and strCarModel will contain the string "Cooper".
Now our variables are declared and assigned, but we need a way to display them on our page (this isn't always necessary, but it is in our example). An easy way to echo the contents of our variables to the screen is by associating them with labels. The following lines create two labels and assign their ".Text" attributes to be equal to our variables. The prefix "lbl" is short for "label" and is optional, but useful. VB.NET:
C#:
Glance down into the body of the page, and you'll see where these labels are placed:
The above are examples of special HTML-ish tags called "ASP Controls." There are many types of ASP controls. This type is called a "label". Think of labels as simple placeholders which you can programatically control. The important thing to notice here is that the ID attribute of each label uses the same name we defined previously. When the ASP.NET engine sees a label control, it uses the ID attribute to decide what to do with the label (in this case, what text should go in it). We've already told it that lblCarMake should contain whatever strCarMake contains. So the first label becomes "Mini". We've also told it that lblCarModel should contain whatever strCarModel contains. So the second label is replaced by the string "Cooper".
You'll notice that our <asp:label> has two other attributes. One is called RUNAT, which is set to "server". This is a required attribute that lets ASP.NET know to process the label. The other attribute is CSSCLASS. We can use this class to associate a CSS class with our label. The CSS for this page is defined inside the HTML header:
While CSS is beyond the scope of this book, you can probably tell easily enough that the style named "box001" has an attribute called "font-family" which tells any CSS-capable browser to display anything associated with "box001" in "trebuchet ms" (if that's available on the system), or verdana (ditto), or whatever is defined as the system's generic sans-serif font (if neither of the previous two exist).
There are a few other things to notice about our example. First, looking back at the top of the page, notice that our postback block is empty, except for a comment. VB.NET:
C#:
For this page, everything happens on page load (which in C#, good coding habits require it to contain inside the parentheses the two parameters - "object sender, EventArgs e"). We don't even have a submit button on the page, so there's no way to post anything. We include the conditional statement just for completeness, in case we intend to expand the page later (which we will do).
In the body of the page, notice that our <asp:label> tags are nested inside some special form tags which have the same RUNAT attribute:
It seems redundant that both the <form> tag and the <asp:label> tag both contain the RUNAT attribute. It is redundant. Get used to that, too.

# Examining the Output Page

If you view the page above in your browser and then choose to view the page's source code there, you'll notice some things common to server-side scripting languages and a few things specific to ASP.NET. I've simplified the VALUE attribute of the INPUT tag for sake of formatting. Where you see "[...]" below there will be a long, incomprehensible string of characters:
A big perk, in terms of security and, for those proprietary projects, secrecy, is that server-side languages hide a lot of code from the browser. When a web browser requests a page from the web server, the server examines the page. If the server recognizes the page as one that needs to be processed by a server-side scripting engine, it hands the page off to that engine for processing. The processing engine (here, ASP.NET) does its work and hands the page back to the webserver, which, in turn hands off the finished product to the browser. The code you see above is all that the browser gets. Note that all the ASP.NET-specific code is gone, though there are some indications that this is an ASP.NET page.
Web servers usually decide which pages go with which sort of processing engines based on their file-name extensions. ASP.NET pages generally end in .aspx (though you can define most anything else by custom configurations of your web server). PHP pages end in .php. HTML pages generally end in .html or .htm.
Notice a few of the changes that happen once our page is processed. The <asp:label> tags have turned into ordinary <span> tags. Their CSSCLASS attributes have become simple CLASS attributes. Their ID attributes remain the same. And the mysterious RUNAT attribute disappears entirely. Our <form> tag is still here, though its RUNAT attribute is gone and several other attributes, common to form tags, have emerged.
Interestingly, along with our <span> tags, a new <input> tag has been added the form. Note that it's attribute is "hidden". Hidden input tags are used in web programming to carry the values of variables from one page to another. If this form contained a submit button, the values of our labels would be passed to the page defined in the <form> tag's ACTION attribute via this <input> tag's NAME and VALUE attributes. In many server-side programming languages, you have to code this feature in yourself. ASP.NET does it for you, if a bit cryptically.