1. Database Form Processing Made Easy Chad Killingsworth Web Projects Coordinator

2. Office or Department Project Background  Migration away from server extensions  Maintain the same level of distributed developer support  Should not require any programming  Follow good security practices

3. Office or Department Development Environment  Web Services Office: Central pages and applications only  Academic and administrative departments have their own web developers

4. Office or Department Project Scope  Basic database forms only: form contents stored in a database  No post-submission processing or multi-step forms  Must allow for submission of secure data (such as SSNs)

5. Office or Department Security Assumptions  Everyone has insert access to the table  Access to the data or to create or update tables is restricted to developers who have rights to modify the web form  Database and table determined by HTTP Referer

6. Office or Department How It Works: Overview  System parses the form and automatically determines the table structure for the user  The more information a user provides, the more precise the resulting table structure

7. Office or Department How It Works: Initial Setup  Developer requests database services for their site(s)  Web Services creates database mappings for the requested URLs

8. Office or Department How It Works  Step 1: Developer creates a form  Step 2: Developer visits Database Management System and updates table structure  Step 3: Developer later visits Database Management System to retrieve data

9. Office or Department Example 1: Simple Form  Single textbox

10. Office or Department Example 2: Complex Form  Session Evaluation Form

11. Office or Department Additional Developer Options  Confirmation Page  Basic form post-processing based on record ID  Developer Notification  Ignored Fields  Table Name

12. Office or Department Advanced Support  Multiple authentication sources  Allows use from with our CMS

13. Office or Department Questions