Last time around we installed all the prerequisites and finally even
ASP.NET. Now that that's done, you can start writing ASP.NET
pages of your very own. This time around, we walk you through
your first one.
Way back when programming was new, someone decided that the first thing
you should do whenever you start programming in a new environment or language
is print out "Hello World." I have no idea who it was that came up
with this idea or why it stuck, but it has. Not being one to fight the
system without reason, we'll be using this incredibly simple idea as the
basis for our first ASP.NET page.
Hello World in HTML
For your reference, I'm going to start with a sample of what we're trying to
accomplish done completely in static HTML:
Ok so that's the goal... now let's try it in ASP.NET.
Hello World in ASP.NET
The Easy Way - Cheating!
Fundamentally, there's no requirement that an ASP.NET page (sometimes
referred to as a Web Form) actually do any processing. As such, the
simplest way to get the task at hand accomplished is to take the
existing HTML page listed above
and simply give it an aspx extension. This results in a perfectly
legal and acceptable ASP.NET page. The only thing that happens when
you do this is that you tell the web server to pass the aspx file through
the ASP.NET runtime, which in turn compiles it and processes any code it
finds (in this case none) before it returns the result to the client.
I'll be highlighting changes from the previous version of the code in
red for emphasis and quickly mentioning them after each new listing.
The only thing that changed here is the filename. If the ASP.NET
runtime doesn't find any code it understands, it just leaves everything
alone and passes it out to the browser.
While that is perfectly legal and runs, it doesn't really get too much
accomplished. In this scenario that's fine, but that's not usually
the case so now we'll move on to a version that actually does some processing.
The Classic ASP Way
One of the nice things about ASP.NET is that it will work with a lot of
classic ASP style code with only minor changes. Anyone who is familiar
with ASP should have no problem making out what is going on in the code
listing below. Besides the use of VB instead of VBScript there's really
nothing to distinguish this from a classic ASP script.
In order to process the inline code (sometimes referred to as a render block)
the server needs to know what language the code will be in. The first line
in red in the code listing above tells the ASP.NET runtime that we'll be using
Visual Basic (VB) as the default language for the page. The second line is a
standard Response.Write line using the <%= %> shorthand most people are
used to from ASP 2/3.
The code listed above probably seemed pretty familiar to most people, but it
illustrates one of the major limitations of classic ASP scripting. In order to
get the phrase "Hello World!" in between the two paragraph tags, you
had to place the code that outputs the phrase where you want the phrase to appear.
This makes it difficult to maintain any sort of structure and is a chief
contributor to much of the so called "spaghetti code" that developers
ended up writing. Unfortunately it's not the writing of it that's hard... it's
the countless hours other developers wasted trying to decipher it that is the
real problem. Enter ASP.NET...
Using Server Controls - HTML Controls
This time around, we're going to introduce what is called a server control.
You can think of a server control as HTML tags for the server. Regular HTML
tags are read by the browser and interpreted in some way determined by what
they contain. The same happens on the server with server controls, and the
first type of server control, called HTML Controls, look very much like
a standard HTML tag. The only difference is that they contain a special
runat="server" attribute. You can see an example
illustrated in the code listing below:
Notice how the same <p> tag from our original document has now become an
active part of the processing of the page. We've given it the
runat="server" attribute which turns it into a
web control. We've also given it an id attribute so we
have a way to reference it in our code. This is how you
give a server control a name. All but the most basic control will need
a name so you can reference it from the code sections of your page.
Notice that the end result of this code is that the section that
actually specifies the text to write out has been moved into a
code section of the page and this code section can be placed anywhere
(ie. not at the point of display!).
FYI: The <p> tag does not have an actual corresponding
HTML control defined and is therefore handled as a control of type
HtmlGenericControl. We'll discuss this more in a future lesson
when we talk more about HTML controls.
Using Server Controls - Web Controls
Web controls are the second type of server control. They are similar to
HTML controls, but tend to be more complex and do not necessarily map
directly to any one HTML tag. This allow them to be much more flexible and
useful. Their object model also is usually more complex. Where HTML controls
tend to have object models that mirror their HTML tag counterparts, web
controls usually have more abstract or "high-level" properties
and methods. Again, we'll discuss them more in a future lesson, but I thought
the earlier they were introduced the better.
The only thing that's changed from the previous listing is the control we're using.
We've restored the original <p> tag so it's now once again a
plain old HTML tag and is entirely ignored by the server and have placed an
<asp:label> tag inside of it. This new tag is now the focus of our
code that sets the text to "Hello World!". Notice how the property
has changed from InnerText to simply Text.
This is because the <asp:label> tag object model is defined differently
from that of the HtmlGenericControl we were using before.
Using Server Controls - Event Handlers
Now that we've decoupled the text writing code from the text's intended
location by using server controls, there's no reason we
can't move it into a little more structured format so that we know when it will execute.
As it stands above, it simply ran when the page gets to that point. By placing it in
an event handler, we can dictate when it runs. Once again, I'm getting ahead of myself
(we'll cover this more in a future lesson), but I wanted to get you to a point where
the code looked closer to the ASP.NET style then it did to that of classic ASP
before I called it quits. Here's the result:
<%@ Page Language="VB" %>
Sub Page_Load(Sender As Object, E As EventArgs)
HelloWorld.Text = "Hello World!"
<title>ASP.NET Hello World</title>
<p><asp:label id="HelloWorld" runat="server" /></p>
Don't worry too much about the Page_Load details at this point.
It's just an event that is called when an ASP.NET page is requested. The point
is that now we know when the text will be assigned to the control and can modify it
as we please without worrying about where on the page it needs to go.
As always happens, we've gotten to the end of this little section.
If you'd like a copy of all the files listed in this article you can
get then in a zip file from here.
Don't worry... I'll be back with new lessons before you know it.