• Create BookmarkCreate Bookmark
  • Create Note or TagCreate Note or Tag
  • PrintPrint
Share this Page URL

Lesson 14. Restricting Access > Finishing the Registration Page

Finishing the Registration Page

In the previous lesson, you built a registration page (index.cfm) to store the information users entered in a database. In the introduction to this lesson, you learned that the survey and test would both be tracked by username. But what happens if two users enter the same username? Or, what if users don't bother to fill out the username field of the registration form at all? In this task, you'll return to the registration page (index.cfm) and make the changes needed to prevent these problems.

Open index.cfm in Dreamweaver and make sure that the Server Behaviors panel is open (Window > Server Behaviors). In the document window, click to select the Submit button.

You should see the Insert Record server behavior, which you added in Lesson 13, still present in the Server Behaviors window.

Click the + button in the Server Behaviors panel to add a new server behavior, and choose User Authentication > Check New Username from the menu.

This server behavior looks in the database when the user submits the registration form data. If the username has not already been taken, then a new record is added and the profile is successfully created. If the username is already taken, then the process is aborted and the user is redirected to registration_error.cfm.

In the Check New Username dialog, choose FORM.username from the Username Field, and type or browse to registration_error.cfm in the If Already Exists, Go To field. Click OK.

If you look at the code generated by this server behavior (try looking in Code View with the Check New Username behavior selected in the Server Behaviors panel), you'll see the following, which you can probably figure out on your own.

							<cfif IsDefined("FORM.username")>
							<cfquery name="MM_search" datasource="elearning">
							SELECT username FROM users WHERE username='#FORM.username#'
							<cfif MM_search.RecordCount GTE 1>
							<cflocation url="registration_error.cfm?requsername=#FORM.username#"

In the first line, the code makes sure that the username field of the HTML form has a value. Then, in lines two through four, ColdFusion executes a query, pulling from the database all of the records whose username field matches the one in the form. The fifth line then tells ColdFusion to search through all of the records that were returned by the query. If the number of records returned is greater than or equal to (GTE) one, then someone has already registered that username. The sixth line (which begins with the <cflocation> tag) redirects the browser to registration_error.cfm. Otherwise (if the returned recordset is empty), ColdFusion proceeds to the Insert Record behavior.

While working with Dreamweaver server behaviors, you don't need to read or understand the code. But looking at the code is a good way to learn a new language, and as you can see, ColdFusion code isn't all that different than the JavaScript code used by DHTML or the ActionScript code used in Flash. With this ColdFusion code, the duplicate username problem is eliminated. But you still need to make sure that your users fill in all the fields.

Click to select the Submit button in Design View. Open the Behaviors panel (Window > Behaviors). Click the + button and choose Validate Form from the list of behaviors that appears.


When you open the Behaviors panel, note that it is not the Server Behaviors panel. Remember that the difference between behaviors and server behaviors is that regular behaviors are client-side JavaScript behaviors that run in a regular HTML document, without the need for a server model such as ColdFusion. Server behaviors are written in the native scripting language of the server model, so CFML for ColdFusion, VBScript for ASP, Visual Basic or C# for ASP.NET, and so on.

Since you are applying the Validate Form behavior from the Behaviors panel, you know that the behavior will be a regular, client-side JavaScript behavior.

When the Validate Form dialog appears, you'll see each of the four fields in this form listed in the main window.

In the Named Fields area, select the first option, text “firstname” in form “registration.” Check the Required checkbox beneath it. Leave the Accept value at Anything.

In this step, you are building a JavaScript that will make the firstName field required, and will accept any value that the user enters.

Select the second option, for lastName. Check the Required checkbox, and leave the Accept value at Anything.

As with the firstName value, these settings force the user to enter a value in the lastName field, but any value is acceptable.

Select the third option, for username, and check the Required checkbox again. This time, change the Accept value to Email Address.

This setting ensures that the value entered in the username field is an email address. More specifically, it makes sure that the value has the following syntax: text@moretext.txt, the syntax for an email address. It does not check the Web to make sure there really is such an email address.

One advantage to forcing users to enter an email address is that once you have their email address, you can send them messages. Obviously, you should respect your user's privacy—this is not an invitation to spam them. But if you have the email addresses of all your students in a database, you can use ColdFusion to automatically generate email messages to them—for announcements, transcripts, or to send password reminders. Such features are beyond the scope of this book, but each is relatively easy to implement, should you decide to learn how to do it.

Select the last option, for password, and again make it required but let its value be anything. Click OK.

Dreamweaver adds the JavaScript to the document that validates the form.

You may notice that Dreamweaver appends a string of text in parentheses after each item that you require. All begin with an R, which simply means that the field is required. The string appended to the username field is (RisEmail), which means that the field is both required and must be in email format. Other possibilities are (RisNum), which means that the field is required and must be a number, and (RinRange1:5), which means that the field is required and must be a number between, in this example, 1 and 5.


One limitation of the Validate Form behavior is that it validates only text fields. It does not validate radio lists, checkboxes, drop-down menus, and so forth. As you will see in the next lesson, ColdFusion makes it easy to validate any sort of form input.

Save the file, put it on the server (that is, in the remote folder), and press F12 to test it. Don't enter any values at all, and click the Submit button.

A JavaScript pop-up alerts you that you did not complete the form. The Form Validation behavior has done its job. It stopped the submission dead in its tracks, and neither the server nor ColdFusion even know that the user attempted to submit the form.

Your registration page is now practically foolproof.



Not a subscriber?

Start A Free Trial

  • Creative Edge
  • Create BookmarkCreate Bookmark
  • Create Note or TagCreate Note or Tag
  • PrintPrint