ASP.Net MVC HTML Forms is the second post in a series of tutorials which introduces the basics of ASP.Net MVC programming.
As noted in my first post, ASP.Net MVC relies heavily on traditional web forms, the ones that have been around since HTML was invented.
Web forms allow form data from inputs such as text boxes, radio buttons, checklists, etc. to be sent to a server for processing. Actually, you can send form data to another HTML page or the same HTML page but to be really useful, data is sent to a server to either store or retrieve data or both.
A common example is entering registration details for a website. You enter you name, email address and password. The details are sent to a server. If the data is valid, a connection a database is made and the data is stored. The server can then redirect the user to a successful registration page or directly into the contents of the website. Otherwise if the data or part of it is invalid, the user is prompted with a warning. Validation can happen on the server or the client or a combination of both client and server. Checking if the user completed the name field could be checked on the client but checking if the user name is already taken can only be checked on the server through a query on the data store of users.
Every HTML form should contain the following attributes:
NameThe form name must be unique for each form on a HTML page. Each HTML page can contain more than one form but each form can only have one submit button.
ActionThe action attribute tells the form where to send the form data. The action should refer to a server side form such as an Active Server Page or a PHP page. The server should have software to process the server pages. Microsoft IIS can process .asp pages and with additional add-ons can process other types of pages such as .php. Apache is a common web server software for .php pages and is available for Windows, Unix an MAC servers. Note: If the Action is omitted, the page will submit the form data to itself.
MethodThe method can either be GET or POST. The GET method appends the form data to the address of the action when the form is submitted. in the above example form the address may end up looking like this:
There is a glaring problem with the GET method. The password is included in the web address which is not a secure way to submit a password. The POST method on the other hand submits the form data without appending it to the web address.
POST should be used generally for form data and GET should be used for search queries e.g. http://www.mysite.com/search?name=Michael. POST queries are useful because they can be bookmarked or written as url addresses. For example you could output an array of links each with a different url depending on the users in a database e.g. http://www.mysite.com/search?name=Michael, http://www.mysite.com/search?name=Tom, http://www.mysite.com/search?name=Sue, etc.
Be careful. If you don't include a method for a form, the default is GET.
HTML Form ExampleThe following is an example of a simple registration form which posts to itself. Create a HTML file named registeruser.html using the following code. Notice the page sends data to itself by appending the form data to the URL.
<link rel="stylesheet" type="text/css" href="style.css">
<form name="registrationform" action="registeruser.html" method="GET">
Name: <input type="text" name="username"><br>
Email: <input type="text" name="email"><br>
Password: <input type="text" name="password"><br>
Confirm Password: <input type="text" name="confirmpassword">
<input type="submit" value="Submit">
In a client server situation, the action would refer to a server page e.g. register.asp and the method would be POST to avoid having the password appear in the URL.
In Classic ASP and PHP, this is how things worked and it works well up to a point, well the point where there are too many forms and files to maintain. Websites often start off with one client page and a separate server page to process form requests and then maybe another to confirm the request. Large websites can end up with hundreds of files in lots of folders which become difficult to maintain. The business logic ends up spread across many files which makes code difficult to mantain and change.
ASP.Net Forms versus ASP.Net MVCMicrosoft introduced ASP.Net Web Forms in 2002 as the successor to Active Server Pages in an effort to improve upon HTML forms. While ASP.Net forms looked good in theory, in practice it was a backward step for web development. State Management was introduced to overcome the short comings of the HTTP Protocol which by design made web client server communications stateless. The desire by Microsoft was to make web development more akin to Windows forms development for which there were numerous developers trying to break into web development. Thankfully, Microsoft have absolved themselves with the introduction of ASP.Net MVC and a return to stateless development or a Restful Service as it is often referred to now.
Restful ServiceMVC is a Restful Service. This means that once a request is made to a server, the server deals with the request and may return data to the client. Once that is done, the server forgets about the client literally. Any additional requests are completely independent of the last request and must include everything required to compete each request. The server doesn't even remember the users credentials for each request but there are ways to standardise how this information is included with each request to minimise code.
SummaryHTTP or AJAX HTTP actions are the method of communication for ASP.NET MVC forms. Understanding the difference between GET and POST is very important to understanding MVC as it is heavily reliant on these methods for communication.
To progress to Controllers which I will cover next, you will need to have the necessary software installed for MVC. My next blog will go through what is need to get you up and going. The good news is that the software is free.