Creating a ASP.NET Contact Form [con't]
Creating the Web Form
With the local web site open, you should see your virtual directory/application in the upper right side of the screen. In order to create our contact form, complete the following steps:
- Right click your application and select Add New Item
- In the Add New Item window, by default web form is selected, leave it selected
- In the file name box, change the file name to contact.aspx, check the box Place code in separate file and then left click Select
You will notice when the editor created our file, it created two:
Working with our presentation file (contact.aspx) first
Creating and analyzing the form
Inside the file, you'll notice that it looks just like any other HTML page. It has a normal HTML structure that you would expect, but behind this ordinary markup, there's a wealth of power and flexibility we'll tap into. You'll notice that by default our editor created a <form> tag. By default, all ASP.NET web forms have a form tag and we'll understand why that's important later in the article. Inside the opening and closing form tag, let's create a basic table structure that will collect first and last name, email, and comments from our visitor as shown below:
As you can see from the example above, we're dealing with an ordinary table with an ID that we can use for controlling the presentational aspect of our page, that is, a style sheet. However, for the purposes of this article, we'll focus on the ASP.NET environment in relation to the form.
Client-server architecture demystified
In the web environment, everything is initiated by using protocols, requests for services or a combination of both. Specifically, when working with server-side technologies on the web developers work in client-server architectures. That is, a client such as a local computer requests through an HTTP protocol that a file be sent to it from a server. In response, a server receives the request, accepts it, and finds the file and returns the file to the client.
In some website environments, the only responsibility the server has is accepting the request, and delivering the file to the client. In other website environments, when dynamic pages exist, such as pages that end in ASP, ASPX, the server accepts the request, notices the page has an ASP extension, and as a result, knows that it needs to read, interpret and parse any server-side code before sending the file back to the client with the parsed HTML included. For a little added clarity, the illustration below clarifies the process.
At this point, you may be wondering how the server knows what to do with these special files. It all boils down to Internet Services Application Program Interface (ISAPI). Every web server has the ability for files to interface with it, specifically by installing dynamic link libraries (DLL) that contain code functions that instruct the web server to interpret the request, and if the file has certain extensions, then parse the server-side code before sending the result back to the browser.
Understanding web controls
If you're coming from the traditional ASP or PHP environment, the way you're used to developing form fields is vastly different in ASP.NET. Instead of using <input> tags, we use web controls. When Microsoft created ASP.NET, it basically reinvented web controls that run on the server-side, and then sends back an HTML equivalent. For example, a text box control is a web control that when parsed by the server generates an HTML input tag. When the generated HTML comes back from the server, the ASP.NET engine includes special values for each control, such as the name attribute, which comes from the ID of the control. We'll see more on that shortly. The most common types of web controls include:
- Text boxes
- Radio buttons
- Drop down lists
- Check boxes
In order to create our ordinary input fields, we'll be using text box web controls. Let's add three of them to our file by using the code below:
As you can see from the example above, our web control(s) look a bit odd, but really they're simple. Using the first one as an example, let's analyze it:
We nest the web control inside a table cell. The web control parts are:
o Instructs the ASP.NET engine to parse this control as in input field in HTML
o Each web control must have a unique name. This also serves the purpose of accessing the controls properties and methods in our code-behind file
o Instructs the control to be run at the server
We purposely left the comments field alone for the moment, but we'll get to it in a moment.
Open the Web site in a browser
In order to see the results of our work, open your preferred web browser and type the following:
Don't be concerned if the page doesn't load immediately. Since the ASP.NET environment compiles each web form into Dynamic Link Libraries (DLL), the first time you load a web form into a browser, it has to compile any code or control before it can render the page. However, as a result, since it's compiled, if there are no changes, subsequent requests for the page should speed up and no delay should be evident.
Once your web page has rendered, to reiterate what the ASP.NET environment is doing, view the source of the page in your browser and you should see this:
As you can see from the example above, the ASP.NET environment has automatically replaced the text box web controls with ordinary HTML input tags for first and last name, as well as email, and has used the ID of the control as the value for the name attribute. Keep note of the view state tag circled in red above, we'll get to that later in the article. Since a comment field is generally thought to contain more text than an input tag, we use a text area tag instead. Let's go ahead and create the text area tag by modifying our file as shown below:
As you can see from the example above, in order to get a <textarea> tag, we use the text mode property of our text box control and set its value to multiline. Save your file and refresh your page to see the results.