14 January 2008
You'll need to know how to set up a dynamic site in Dreamweaver and also have PHP and MySQL set up on your development system. You'll also need to understand how to restore a SQL file to a MySQL database.
Dreamweaver has all the power you need to establish an online registration system in PHP, including the administrative back end. The article Creating an event registration application in PHP describes how to set up the front end, including presentation catalog and attendee registration. This article details the creation of the administrative side of the system: listing registrants, adding new ones, and updating or deleting existing attendees. In addition, you'll learn how to make it all secure with protected log-in pages. This application consists of six pages:
Before you begin building the application, take a moment to examine the database tables that are employed and ensure that the database connection is properly set up in Dreamweaver.
Note: It's a good idea to have your dynamic PHP site already set-up at this point and have unpacked the sample files into the local root folder.
The database that accompanies this article is a relatively simple one with 3 tables: presentations, registrants and admin.
The first table, admin, is by far the smallest, but it is vital for any administrative application. The admin table contains the username and password (see Figure 1) for authorized administrators, which is verified at log in.
As described in this article's companion tutorial, Creating an event registration application in PHP , the presentations table maintains information for the various sessions held during the event. The table includes data columns for storing the presentation's name, a short description, and a longer description. There are also columns for the date and time of the talk, its duration and the day of the event (1, 2, 3, and so on) on which the presentation is given. Speaker details, such as name and file name for a picture, round out the table schema.
In comparison, the registrants table has far fewer data columns. Only columns for the registrant's first name, last name, e-mail address, and event name are included. You could—and probably would—require a much more robust set of data columns for an actual application, but this structure should give you a good sense of the type of information you can gather.
The SQL file for the Subscriptions database is included in the sample files download. You can recreate it on your test server through any number of utilities, including phpMyAdmin, MySQL Control Center or MySQL Administrator.
After you've established your database, it's time to create a connection to it in Dreamweaver. To do so, follow these steps:
With your PHP dynamic site, MySQL database, and Dreamweaver connection all established, you're ready to build the first page of the application.
The log-in page is straightforward. It consists of a form with two text fields, one for the user name and the other for the password. Setting up the server-side code for this page is equally direct and requires a single server behavior.
In the sample file, the two fields are named appropriately: User Name and Password. The password field, additionally, is set to mask the entered values (see Figure 3).
When activated by clicking the Log In button, the Log In User server behavior verifies that the entered user name and password match the values found in the admin table. If a match is found, the initial administrative page, reg.php, is displayed; if not, the log-in page is reshown and the user name and password fields are cleared.
Note: For your convenience, a record has already been added to the admin table with the user name of admin and password of pass. Use these values when testing your sample application.
The first page the administrator sees after logging in acts as a central action center for managing the registrants table. The key element is a table that displays the registrants data at a glance. Each row represents a single record which, in addition to showing the attendee's name and number of days attending, provides links for updating or deleting the record. The page also contains a link for inserting new records.
To set up the table of data, the first step is to establish a recordset. While populating the table is mostly a drag-and-drop affair, you'll need to do a little hand-coding to display the registered days effectively, as you'll see in the following steps.
The reg.php includes a prepared table as well as a link to insert a new registrant (see Figure 5).
Note: All of the pages in this application are based on a Dreamweaver template. If you take a look at the Template Properties for this page, you'll notice an interesting addition: an optional region called Logout. When this option is enabled, a Log Out link appears in the footer. This template property is disabled for both the log-in and log-out pages.
With your recordset defined, it's time to add the dynamic data to the page.
If you were to preview the page now and the first registrant had chosen to register for both days of the event, you'd see a -1 in the Days Registered column. To make that data a bit more informative, you have to do a minor bit of hand-coding.
<?php echo $row_rsRegistrants['RegDay']; ?>
<?php echo ($row_rsRegistrants['RegDay'] == "-1" ? "Both" : $row_rsRegistrants['RegDay']); ?>
I've highlighted the new code in red to make it easy to see the changes. This type of code is called a conditional or ternary statement and is basically a condensed if-then series of statements. Translated to English, this code would read, "If this RegDay value is equal to -1, then print Both, otherwise, print the value itself."
Next, you'll add the links to the action keywords in the final column of the table.
To make it easy to manage individual registrant records, an Action column is incorporated. The administrator has the option to update or delete any record. As these actions are executed on their own pages, a link passing the appropriate value is required.
At this point, the page would display a single record. For the final phase, you'll add a Repeat Region server behavior to display all the records in the recordset.
When you select the data to be repeated, you generally want to make sure to enclose everything in a <div> tag and handle the separation through CSS.
Note: If your registrant list grows too long for a single table, you'll want to restrict the Repeat Region server behavior to 10 or more records and include the Dreamweaver recordset navigation (Insert > Data Objects > Recordset Paging > Recordset Navigation Bar).
Although for the most part, your attendees will self-register online, you'll want to be able to add new registrants administratively for the exceptions to the rule. The reg_insert page uses the standard Dreamweaver Insert Record server behavior and, when finished, redirects to the reg.php page so you can see your results immediately.
This page includes a form with three text fields (RegFirstName, RegLastName, and RegEmail) as well as a select list, RegDay, and a hidden field, RegEvent (see Figure 10). The hidden field is set to the current event, Realty Conference, and should be adjusted for any other event.
Note: It's a good idea to name your form elements the same as the corresponding data column. Dreamweaver's Insert Record and Update Record server behaviors all automatically assign such pairs dramatically reducing the workload.
With the form fields named appropriately, Dreamweaver automatically assigns each to the proper data column, so there's no work to do in the Columns area.
Now that you can add a new record to the database, let's make it possible to update existing ones.
Because you're modifying an existing record, setting up the reg_update.php page is a three-step process: First, you'll define a recordset that gets the desired record. Then you'll bind the dynamic data to form field elements. Finally, you'll add the Dreamweaver Update Record server behavior.
Remember when you set the Update link to include the special parameter ID? In this step, you'll use that parameter value to filter the recordset down to just one record.
The reg_update.php page is quite similar to the reg_insert page (see Figure 12), with two significant differences. Instead of a select list, a text field is used for the Days field because the proper values could not both otherwise be initially displayed and inserted. To make it easier for the user, a bit of helper text is added. The second difference is the hidden field. Here, the hidden field is named RegID and will contain the ID of the selected record—a necessary step for the Update Record server behavior.
URL Parameter: ID
The Filter setting gets whatever is defined in the ID variable and uses that to select the recordset.
Now that the recordset is defined, set the dynamic values for the various form fields.
Next complete the reg_update.php page by adding the Update Record server behavior.
Once again, Dreamweaver automatically assigns each to the proper data column because of the properly named form fields.
Occassionally, you'll need the capacity to delete a registration from the system. The Dreamweaver Delete Record server behavior is perfect for the task. Again, you'll need to set up a recordset for the task—luckily, Dreamweaver provides a shortcut to reduce the workload.
By now, this layout should seem very familiar (see Figure 16). There is, however, a notable difference: Rather than form fields, empty table cells will be used to hold the dynamic data.
As mentioned earlier, take advantage of a Dreamweaver shortcut to add the needed recordset to the page.
Because the recordset on both the Update and Delete pages is filtered by the ID parameter in the URL, you can simply copy and paste. Next, bind your data.
The dynamic text is added to make sure that the record about to be removed is the right one. Now you're ready to add the server-side code.
By setting the Primary key value to the hidden form field, you're assuring that Dreamweaver will display this confirmation page. If you set it to the URL variable, the deletion would occur without confirmation.
All of the major record manipulation is now complete. There are just two more tasks remaining, the first of which is making it possible for the administrator to log out.
When Dreamweaver logs in a user, it creates a session variable that makes it possible for anyone to use the machine at the current time to access restricted pages. A log-out page is important, because it eliminates that session variable and thus prevents any unauthorized access. Dreamweaver makes it easy to accomplish.
Although this page has a Log Out title and a bit of confirming text, in reality it will never be seen by the user. The server behavior executes when the page loads and immediately redirects the user to another page.
Since the user has already clicked Log Out once to get to this page, you'll want to grant his or her wish immediately.
The final task is to protect your various pages from unauthorized access.
Now that all of your application pages are ready to go, it's time to shield them. As you'll recall, the log-in server behavior includes an option to restrict access based on user name and password. To activate that protection, you'll need to apply the Dreamweaver Restrict Access to Page server behavior to the desired pages, starting with reg.php.
Dreamweaver does offer a more expansive authentication protocol that also looks at the users access level. For your purposes, the Username and Password option is good enough.
With this page protected, you're ready to move on to the other pages in the application.
Congratulations! You've created an entire administrative application for your event registration system. To test your application, open login.php on your testing server and log in with the user name admin and password pass. From there, you'll be able to view existing registrants and update or delete their records or add new ones. Enjoy!
This article covers the development of a complete administrative application for the registrants table in the database. A comparable set of pages would need to be created for any additional tables, such as presentations or admin for a complete administrative site. I leave this exercise to you to complete; you can apply the concepts in this article to building such applications.