End User Recipe: Personalizing and Protecting Pages

It's generally a good idea to provide feedback to a user's action, whether the action succeeds or fails. The feedback can take many forms: A simple thank-you page is often used. However, the more personalized the feedback, the better. By including information the user submitted on the form, you demonstrate that you actually did receive the data. In this recipe, you'll see both how to acknowledge receipt of a form submission in a personal manner and how to protect a page from unregistered users.

Step 1: Implement the Content Design

The first step is to create a page to hold the dynamic content. The Recipes example is rather stark with its title of Protected Page [r1-9], but that's just to keep the concept clear. You are free (and encouraged) to develop your own design.


Figure r1-9.

graphics/03fig09.jpg


  1. Create a basic dynamic page either by hand or from a template.

    graphics/book.gif In the UserLogin folder, locate the folder for your server model and open the protectedpage page found there.

  2. Add a table to the content region of your page to contain the interface elements for the application.

    graphics/book.gif From the Snippets panel, drag the Recipes > UserLogin > Wireframes > Protected Page - Wireframe snippet into the Content editable region.

  3. Within the table, insert a content table with the necessary text and a form button. No form is necessary for this application.

    graphics/book.gif Place your cursor in the row below the words PROTECTED PAGE in the second cell and insert the Recipes > UserLogin > ContentTables > Protected Page - Content Table snippet.

  4. Save your page.

Step 2: Add Database Components

To demonstrate to the user that he is properly logged in, this application will pull his data into a recordset and then display a few of the fields on the page. We'll target the recordset by using the session variable created on the login page, UserID.

  1. From the Bindings panel, select Add (+) and choose Recordset (Query).

  2. The Recordset dialog has two views: simple and advanced. Make sure you are in simple mode [r1-10].


    Figure r1-10.

    graphics/03fig10.gif


  3. In the Name field, enter the label for your recordset.

    graphics/book.gif Enter LoggedIn as the recordset name.

  4. From the Connections list, choose the desired data source connection.

    graphics/book.gif Select Recipes from the Connections list.

  5. Choose the appropriate table containing the users information.

    graphics/book.gif Select Users from the Table list.

  6. Choose the Selected option under Columns and select only the necessary columns for this recordset.

    graphics/book.gif Choose UserID, UserName, and UserEmail by Ctrl-clicking on each column.

    It's always a good idea to limit the number of columns to the lowest number of usable items.

  7. In the Filter area of the Recordset dialog, set the four Filter list elements like this:

    graphics/74fig01.gif

    Effectively, what we are doing is limiting the recordset to the data from just one individual the one currently logged in requesting the current page.

  8. With just one record, no sorting is necessary. Click OK to confirm your choices and close the dialog.

We now have all we need to output a personalized response.

Step 3: Display Profile Data

In this step, we'll insert the dynamic data from the recordset. Although you could use the Dynamic Text server behavior to make this addition, it's more intuitive not to mention a bit quicker to drag the two fields from the Bindings panel.

  1. From the Bindings panel expand the recordset, if necessary.

  2. Drag the UserName (or corresponding) field onto the page just after the User Name: text.

  3. Drag the UserEmail (or similar) field onto the page just after the Email Address: label [r1-11].


    Figure r1-11.

    graphics/03fig11.jpg


  4. Save your page before continuing.

You can test your page by entering Live Data view. The first time you preview the page, Dreamweaver will present a dialog asking for a MM_UserID session variable value. Enter 1 or whatever number represents a valid entry in your UserID field.

Step 4: Restrict Access to Pages

Our registration system is in place, and it's time to protect our page from unauthorized viewing. Dreamweaver supplies a very handy server behavior that does the job nicely: Restrict Access to Page. With this server behavior, you can restrict access based on a matching username and password, or you can extend the restriction to check access groups. The Recipes application uses the latter approach for maximum flexibility.

  1. From the Server Behaviors panel, choose Add (+) and select User Authentication > Restrict Access to Page.

  2. Choose the Restrict Based On Username, Password, and Access Level option.

    With the Access Level option chosen, the Select Level(s) area becomes active. Before we can select which levels to allow, we need to define them.

  3. Choose Define to open the Define Access Levels dialog [r1-12].


    Figure r1-12.

    graphics/03fig12.gif


  4. Click Add (+) and enter the name of the access level as it appears in your data source.

    graphics/book.gif The Recipes data source uses a numbering sequence (1 to 4, where 1 is the highest level of access) rather than words to indicate levels. Enter each number on its own line.

  5. Repeat step 4 for each level and click OK when you're done to close the Define Access Levels dialog.

  6. In the Restrict Access to Page dialog, Shift-select all the access levels to allow all logged-in users to see this page.

    Obviously, when this behavior is applied on different pages, different access levels will be selected.

  7. In the If Access Is Denied, Go To field, choose your login page.

  8. Click OK to close the dialog box.

Once the Restrict Access to Page server behavior is inserted in a page, visitors cannot go to that page without logging in. If they try, the code redirects them to the user login page.

The Restrict Access to Page server behavior is very powerful, but it has to be inserted on all pages. One way around this chore is to insert the server behavior on the template rather than on individual pages and have Dreamweaver do the installation work for us. It's best to set the server behavior to allow all access levels and then, on a case-by-case basis, restrict the access levels as needed.

graphics/book.gif

To use the template approach, open the userlogin template for your server model and apply the steps covered in the last action. Save the template and update all pages. The administrative recipe pages edit_user, user_manager, and user_statistics should be opened individually so that the access levels can be reset to 1, the administrative level.


Step 5: Add Link to Update Profile Button

Everyone makes mistakes entering form information sooner or later. Once you press the submit button, the data you entered goes right into the data source, and it's always good to provide a way for the user to amend his entries. In this step, we'll link a button to another page in the application.

  1. Select the Update Profile form button.

  2. From the Behaviors panel, choose Add (+) and select the Go To URL behavior.

  3. Enter the path to application page for editing user profiles.

    graphics/book.gif Select the Browse button and choose the edit_profile page for your server model.

  4. Save the page when you're done.

Obviously, you don't have to use a form button and a JavaScript behavior to get the linking functionality; a text or graphic with a standard link would work as well. On the other hand, the form button provides a certain degree of continuity with the other form elements in our application without having to expend resources to develop suitable graphics.



Macromedia Dreamweaver MX 2004 Web Application Recipes
Macromedia Dreamweaver MX 2004 Web Application Recipes
ISBN: 0735713200
EAN: 2147483647
Year: 2003
Pages: 131

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net