Preparing the Content Management System

Though it is often tempting to open Dreamweaver and start building pages right away, when you are developing a Web application, you are better served by thinking through exactly what you want to create, and at least outlining the major file assets that you need. The goal of this content management system is to create a group of pages that let users insert new country profiles, and modify or delete existing profiles.

You already should see a distinction between these two processes: When inserting a new record, you can just create a form that collects the data to be inserted, but to allow users to delete or modify existing records, the users need to be able to specify a record. In other words, the insert page doesn't require a master-detail page pairing, but both of the other two functionalities do. There's no reason, though, that the pages that enable users to modify versus delete records can't share the same master page.

Each of the three functionalities requires a script to do the actual work of inserting, updating, or removing records. The easiest way to implement these scripts is to put them on their own pages, using the _processor suffix we have used throughout the book. Once a given script is processed, we'll redirect users to the master page, so they can verify that the correct action has been taken. These pages are hidden because they are active for only the split second required to process the script before redirecting the user to another page.


Though it is easy to store these scripts in hidden files, many developers actually put them on the same page as the form, and have the page submit the form to itself. An if…else structure near the top determines whether the form variables are present, and if so, processes the script. If not, it skips over the script and displays the page. This approach reduces the number of files on the server, but there are some advantages to keeping scripts separate. First, a good programmer can write reusable scripts, using the same script for multiple pages. Second, you can place scripts in a special folder, with special permissions on it to enhance security.

The following figure summarizes the pages needed to create this application.


Starting from admin_index.asp, users can choose either to insert a new country profile (in which case, they are redirected to admin_cp_insert.asp) or modify/delete an existing country profile (in which case, they are redirected to admin_cp_master.asp.

The admin_cp_insert.asp page contains a blank form. Users will fill out this form when they want to create a new country profile. When they submit the form, the data is sent to admin_cp_insert_processor.asp, where it is inserted into the database and users are redirected to the master page. The new country's presence on the master page is proof that the insert action was successful.

Once on admin_cp_master.asp, users can click a link to modify an existing record, in which case they are taken to admin_cp_update.asp, which contains a form whose contents are already filled in with existing data. They can modify this data, and when they submit it, a script (on admin_cp_update_processor.asp) updates the database with the new data and redirects users back to the master page. They can view the profile again to verify that the update was successful.

Alternatively, from the master page, users can choose to delete a country profile. When they click this link, they are redirected to admin_cp_delete_processor, which contains a script that deletes the selected country and redirects users back to the master page. This process takes a fraction of a second and appears to users as if they never left the master pageit simply updates with the selected country removed.

Now that you have a firm grasp of the basic layout of the content management system, you can start building it.

  1. Using admin_template.asp as the source, create each of the pages that the user will see, as follows.




    These three pages are visible to the user, so don't delete the code and be sure to customize each accordingly. Add a page title in the toolbar, and overwrite the placeholder heading at the top of the page with something appropriate, such as "Insert a New Country Profile" or "Select a Country Profile to Modify or Delete."


  2. Create each of the hidden pages as well, saving three files (as follows). Be sure to delete all code from these pages, while in code (not design) view.




    These pages should never be displayed to the user, and so they should not have any HTML code in them. They will contain only the code needed to perform the function (insert a new record, update a record, and so on.).


    The easiest way to complete this step is to create a new file, strip out the code, and save it three times with different filenames.


    You now have six new files. Granted, they are empty, but now that they exist, it will be easier to link to them as you build the application itself.