| Now that you've added the functionality for employees to register on the site, you'll want to add more functionality to allow them to modify the information they provided. Suppose that an employee moved to a new location and you shipped a product to their old address. You could imagine the confusion. Fortunately, Dreamweaver provides a behavior in the Update Record server behavior that enables you to develop a page for user administrative purposes such as these. Using dynamic form objects in conjunction with the Update Record server behavior, employees can see the information that resides in the database in editable form objects. After an employee edits the appropriate information, they need only submit the form to update the information in the database. Creating the My Account Form Because all the information is placed into form objects, the My Account form will be constructed much the same way that the New User Registration form was. To create the My Account form, follow these steps: 1. | Begin creating the My Account form by creating a new page from a template. From the File menu, select New, navigate to the Templates tab, and select the template named Template from the site you're working with.
| 2. | Remove the Content text from the editable region. With your cursor still in the region, insert a new form by selecting Insert, Form, Form.
| 3. | Let's add a table similar to the one we created in the New User Registration form. Choose Insert, Table; the Insert Table dialog appears. In the dialog, create a table that has 14 rows, 2 columns, a width of 450 pixels, and 0 border, cell padding, and cell spacing. Click OK to create the table.
| 4. | Add all the appropriate content for personal information including billing/shipping information, and so on within the table. You can merge cells along the way to create the header. The result is shown in Figure 26.12.
Figure 26.12. Add all appropriate content to the new table. 
| 5. | You are now ready to begin adding all the form objects for the My Account form. The following matrix shows the fields, the appropriate form objects to be inserted, and the unique names to be given to each of the form objects.
|
Field Name | Form Object | Name |
|---|
EmployeeID | Hidden Field | employeeid | Name | Text Field | name | Username | Text Field | username | Password | Text Field | password | Email | Text Field | email | Phone | Text Field | phonenumber | Headshot | Text Field | headshotloc | BillingShippingAddress | Text Field | billshipaddress | BillingShippingCity | Text Field | billshipcity | BillingShippingState | Text Field | billshipstate | BillingShippingZip | Text Field | billshipzip | | | Submit Button | Submit |
The result of inserting all the form objects is shown in Figure 26.13. Figure 26.13. Insert all the form objects for the My Account page. 
Recall that when we created the New User Registration page, we had a Hidden Field for DepartmentID. Because the user won't be able to modify the department they belong to, we won't make that value available in this form. (The administrator is responsible for changing this value.) We have, however, replaced the DepartmentID Hidden Field with an EmployeeID Hidden Field. When updates are made to a database, you as the developer must specify which field will be updated. In Chapter 24, "A SQL Primer," we discussed the WHERE clause. The value, typically a numeric primary key, is appended to the WHERE clause so that application logic knows exactly which record in the database table to update. This numeric key is the EmployeeID. Save the page as myaccount.asp, myaccount.cfm, or myaccount.php (depending on the server model you're using). Working with Dynamic Form Elements Now that you have the My Account form created, you'll want to make all those form objects dynamic, meaning that when the page is loaded, corresponding fields from the Employees table automatically appear in the form objects. In the previous chapter, you learned how to create dynamic text by dragging an item from the recordset onto the page. Dynamic form objects are constructed much the same way in that you can drag an item from the recordset (in the Bindings panel) directly onto the form object to which you want to bind that field. Dynamic form objects can be created using one of three methods: Dragging a field from the recordset onto the form object. Using the Dynamic Form Elements server behaviors set. Selecting the form object and clicking the lightning bolt icon in the Properties Inspector to create a binding.
Any one of these three methods will do the job. Dragging an item from the recordset into the form object is probably the easiest and quickest way to accomplish the task, but for the sake of learning all the methods, try binding at least a few of the form objects using the following process: 1. | Before you can bind text to a form object, you'll have to create a new recordset. To do that, select the Recordset option from the Bindings panel's Add (+) menu. The Recordset dialog appears.
| 2. | Enter the name rsUpdateEmployee, select the connDorknozzle option from the Connection menu, choose the Employees option from the Table menu, and click OK. The new recordset is created.
| 3. | Select the Dynamic Text Field option from the Dynamic Form Elements submenu by clicking the Add (+) button from the Server Behaviors panel.
| 4. | The Dynamic Text Field dialog appears similar to figure 26.14, allowing you to select the form object you want to make dynamic. Select the "Name" in Form "Form1" option from the Text field menu.
Figure 26.14. The Dynamic Text Field dialog allows you to create a binding from the recordset to the form object. 
| 5. | Click the binding icon (the lightning bolt) to set the binding for the name text field. The Dynamic Data dialog appears similar to Figure 26.15.
Figure 26.15. Click the binding icon to set the value of the dynamic form element. 
| 6. | From the Dynamic Data dialog, select the field from the recordset to which you want to bind the object (for our example, choose Name). You have the option to change the data type as well as the capability to modify the code if necessary.
| 7. | Click OK.
| 8. | Notice that the Set Value To text box in the Dynamic Text Field dialog now has the value set with the appropriate code. Click OK to complete the binding. Figure 26.16 shows the Name text box with the Name field bound to it. Also notice that the Properties Inspector shows the bind in the Init Val field.
Figure 26.16. The field should now be bound to the appropriate form object. 
| 9. | Up to this point, you used the Dynamic Form Elements submenu in the Server Behaviors panel to create the binding. As mentioned earlier, there's an easier and much more intuitive way: dragging and dropping from the Bindings panel. To use this method, switch to the Bindings panel and expand the Recordset node.
| 10. | Drag the Username field into the Username text box similar to Figure 26.17.
Figure 26.17. Drag the Username field into the Username text box to create a binding. 
| 11. | Repeat the process for the remaining text fields in the My Account page. Don't forget the employeeid Hidden Field; this is by far the most important binding!
|
Save your work and test the results in the browser by pressing F12. The result should look similar to Figure 26.18. Figure 26.18. The first record in the Employees table is displayed in the My Account page. 
Notice that the first record, (Ada's information) is displayed in the My Account page. This is because the application doesn't know who we are or what field is representative of us in the Employees table. In Chapter 29, "Security and User Authentication," we'll add functionality that allows the My Account page to identify our login with a specific row in the Employees table. Ultimately, the login functionality we will add will display the appropriate data in the My Account page. Updating a User in the Employees Table Now that you have the form created and all the objects are bound to the appropriate data fields, you are ready to add the functionality that enables users to modify their particular information. Remember the EmployeeID Hidden Field you added into the form? This number is eventually used in the WHERE clause of the update to track which employee we should modify information for. If it weren't for this field, the Update Record server behavior wouldn't be able to function properly. To add the Update Record functionality, follow these steps: 1. | Place your cursor in the form and select Update Record from the Add (+) menu in the Server Behaviors panel. The Update Record dialog appears.
| 2. | The Update Record dialog functions similarly to the Insert Record dialog except for the fact that you are required to specify the unique key column. For starters, select connDorknozzle from the Connection menu.
NOTE As was the case with the Insert Record server behavior, the Update Record server behavior functions the same across the board for the ASP, ColdFusion, and PHP server models. There are slight differences however; the Update Record dialog for the ASP server model features a Unique Key column menu. From this menu, you would select the EmployeeID value and set the status of the form element in the Form Elements list to <ignore>. In the ColdFusion and PHP server models however, this menu doesn't exist. For these server models, you must pass the EmployeeID value. Next to the Submit As menu, enable the check box labeled Primary Key; making sure that check box is selected ensures that the form updates without failure. | 3. | Now choose the Employees table from the Table To Update menu.
| 4. | Make sure that the rsUpdateEmployee recordset is selected from the Select Record From menu.
| 5. | To append the EmployeeID to the WHERE clause of the UPDATE statement that the Update Record server behavior will eventually generate, select the EmployeeID option from the Unique Key column menu.
| 6. | Enter the value x_userupdated.asp, x_userupdated.cfm, or x_userupdated.php (depending on the server model you are using). As was the case with the New User Registration form, this is the page the user will be redirected to after they've made their update.
| 7. | Make sure that the form1 option is selected from the Get Values From menu.
| 8. | Like the Insert Record dialog, the Update Record dialog allows you to match up the form elements in the form with the appropriate fields in the database table. For the most part, all the form elements should be matched up for you. Remember that you must select <ignore> for the EmployeeID form element. You'll end up receiving an error if you try to update this field, because it is an automatically generated number in the database and cannot be updated. Figure 26.19 shows the Update Record dialog with all the necessary values set.
Figure 26.19. Complete the modifications to the Update Record dialog. 
| 9. | Click OK. The new Update Record server behavior appears in the Server Behaviors panel, and the form is highlighted in blue (because it is an invisible element).
| 10. | To complete the My Account page, create a new page from the site's Template and call the new page x_userupdated.asp, x_userupdated.cfm, or x_userupdated.php depending on the server model you're working with. On the page, enter the text Your information has been modified.
|
Switch back to the My Account page, save your work, and test the result in the browser. After the form appears, change a value in the form (I'll modify Ada's name) and click Submit. Figure 26.20 shows the result of the change in the database. Figure 26.20. Ada's name in the database has been updated based on the value I specified in the form. 
|
