After you run the setup program, you can start using the Training application. The application uses a series of public folders that store all the application's information. Figure 15-2 shows the application's folder hierarchy. As you can see, the types of folders range from standard message folders to contact folders and calendar folders.
The classes are contained in the Schedule folder, while student information and instructor information are contained in their respective contact folders. The application interface is the default training page, which is different for instructors and for students. The instructor home page is shown in Figure 15-3.
From the home page, you can retrieve the schedule of classes, view information about instructors, change your notification preferences, or, if you are an instructor, create a new course. The application determines whether you are an instructor by using Windows 2000 security groups. The application searches the instructor security group you specify in the setup program and checks to see whether the user accessing the application is a member of that security group . If the user is a member of that security group, the instructor-specific content will appear on the Web page. Figure 15-4 shows the Instructors Properties dialog box as it appears when you display the group's properties in Active Directory Users And Computers.
Note that the Training application creates its folders in the Public Folder hierarchy. I coded the application in this way so you can see the folders in Outlook. However, if I were to actually deploy this application, I would not create the folders in the Public Folder hierarchy because the hierarchy is Web-based. Instead, I would create a new top-level hierarchy, not visible by Outlook, to contain my application. This would enable me to conduct deep searches of the folders using ADO and would prevent access to the application from Outlook.
The application allows an instructor to create courses and register students for them. When an instructor creates a course, the application asks her whether she wants to create a file share for course materials or a discussion group for the course. This functionality demonstrates how to use the Installable File System (IFS) components of the Web Storage System through the file share capabilities, and it illustrates the reusability of OWA. Figure 15-5 shows a course listing that contains links to both the course materials and a discussion group for the course.
After an instructor creates a course, an asynchronous or timer event (depending on which you specified in the setup program) fires in the Schedule folder. This event checks to see whether any students have asked to be notified when new training is available in the specific course category. As the application administrator, you must specify these categories ”for example, Developer , End User , and IT . If the application locates students who need to be notified about the training, it sends the students an HTML-formatted message, as shown in Figure 15-6.
The notification preferences of each student are stored on their respective contact record in the Students folder. Students can change their preferences for notification through the application's Web interface, as shown in Figure 15-7.
The application provides two ways for students to browse through the available courses in the Schedule folder. First, a student can specify date ranges from a Date Picker control and view the courses in a simple list. The student can then re- sort the list by title, date, or category. The page containing this simple list is shown in Figure 15-8.
Note | You can generate the simple list page shown in Figure 15-8 in two ways. One way is to use ADO inside ASP pages. The other technique involves using the XMLHTTP component of Microsoft Internet Explorer and requesting XML data from the Exchange server. The Training application then renders that XML data locally, thereby eliminating a round-trip to the server if the user wants to re-sort the list of classes. |
The second way that students can browse through the available courses leverages the extensibility of OWA. By passing OWA-specific parameters (which are covered in more detail in Chapter 20), you can make OWA display information. Figure 15-9 shows how the Training application employs the rich calendar views of OWA to display the schedule of courses.
When a user double-clicks on one of the calendar items in the view, the application displays a custom Web Storage System form instead of displaying the standard OWA appointment form. The ability to replace OWA forms with your own is a powerful one. Figure 15-10 shows the Web Storage System form displayed when a user clicks on a training event in the calendar.
The Training application also offers students and instructors two ways to quickly find course information: quick search and advanced search. Both types of search eventually follow the same code path , but the advanced search provides a more powerful interface for specifying search options. Figure 15-11 shows the Advanced Search page of the Training application. The search capabilities can take advantage of the built-in content indexing of Exchange Server if you enable content indexing. You'll learn about content indexing later in this chapter.
The Training application uses the built-in workflow engine and the graphical Workflow Designer of Exchange Server. If an instructor specifies that a course requires approval, the application starts a workflow process when a student attempts to register for the course. The application sends an e-mail to the student's manager, who can then approve the student for the course. If the manager rejects the request or doesn't approve it in time, the student can't take the course.
Figure 15-12 shows the workflow process in the Workflow Designer for Exchange Server. Figure 15-13 shows the e-mail that the manager receives when an approval is required for a student to take a course.
The Training application also provides a survey component. A timer-based event fires on the Exchange server every night to implement the course survey component. This event checks to see whether any courses have been completed on that day. If a course has been completed, the timer agent e- mails a notice to the students who were registered for the course, as shown in Figure 15-14. The students can then click on a link in the e-mail message and fill out a survey to rate both the course and the instructor. The application checks to make sure that students don't fill out multiple surveys for either the course or the instructor. Figure 15-15 shows a survey form for a course.
After the student fills out the survey, the survey is saved into one of the Surveys folders, depending on whether the survey is a course survey or an instructor survey. The survey agent collates all surveys received for the course and the instructor and determines an overall rating for each. The agent also takes any comments from users and adds them to the course or the instructor rating. Figure 15-16 shows how the final results look after the agent completes its processing. Other students can then view ratings and comments about the instructor or the course.
Now that you've had a quick overview of the Training application, let's look at how the application was actually built. We'll look at the technologies used and examine some code snippets from both the setup program and the application itself.