We will be using Director in combination with MySQL and ColdFusion MX to create a booking facility for the Oakbridge Community Center. The booking facility needs to perform a number of tasks:
It will need to keep a running list of the facilities the visitor wants to book.
It must also include functionality to enable the visitor to change his or her mind and add or delete items.
It should also include the capability to refuse a booking based on over-booking or, if the facility is unavailable, provide a few alternative dates or times that can be booked.
It should also be able to issue an email confirmation regarding the booking.
This tells us exactly what needs to be done in Director. We will need to create a Director movie that:
Develops a list of the facilities to be booked based upon date, which is provided by the database.
Checks a database to ensure the entry on the list does not conflict with a prior booking.
Remains flexible until the data is sent to the database. By enabling the user to change his or her mind, the data can't be sent from Director until the user chooses send it. As soon as a user selects a spot and clicks Book, it sends the data to the database.
Has the capability to generate a confirmation email confirming a booking.
Adds the confirmed booking data to the database.
As you can see, there are two different agendas at play here. There is a list of what the facility needs to do, and there is a list of the functionality that must be built into Director to meet those needs.
Still, Director MX or, for that matter, Flash MX 2004, are merely front ends to do all the UI stuff (like display calendars, turn the data into something the user can understand, and create time slots to book, as well as determine if the user himself owns any of the bookings). The real "work" is being done by the database, and Director and Flash are used as intermediaries to display information from the database or to pass information to the database.
For example, assume a visitor wants to book a tennis court. When the user makes that decision, Director, functioning as the database interface, will determine how many courts are available and send that information to the visitor. If there are three courts and two are already booked, Director will grab that information and tell the visitor that only court 3 is available and ask if he or she wants to reserve the time. In addition, this all must be done in real time in case other members are online and attempting to book a court. If the visitor takes the time presented, Director will fire the information back to the database, and the visitor will be informed onscreen and through email that the court is reserved.
As you can see, there is a fine line between features and functionality. After both are determined, the team can develop a plan that addresses the needs and the functionality of the booking facility and use the features of Director that make the project work.
Before starting the project, you have to look at creating the logic that will drive the application. As we pointed out in Chapter 4, "Planning the Data for a Dynamic Site," the biggest mistake you can make is simply to make it up as you go along. You really should map the logic before you start. This way, everyone involved with the way the data flows understands the functionality of the application. The database developer can create the tables and fields that meet the logic flow, and the Director developer can plan to write the Lingo code that makes it all happen.
In the case of the booking facility, it all starts with an entry point in a Director presentation. The logic map, Figure 11.1, provides a detailed overview, but it won't hurt to walk through the process of booking a tennis court.
When the visitor arrives at the page, the first thing that happens is, if he or she isn't logged into the page, he or she will have to log in. After the visitor is identified, the list of selections will be presented, and the visitor clicks on the tennis court.
If it is unavailable?Can this facility be booked??alternate times will be presented. If it is available, a calendar showing the bookings for that day is presented. The member then clicks on the requested time.
Again the database is checked to see if the time is available, and the reservation is added to the database. The member is then asked if he or she would like to book another time. If the answer is yes, the procedure starts all over again.
If the member decides he or she doesn't want to choose a different date from the one he or she needs, the next section, Figure 11.2, kicks in. All this section does is ask if the member wants to remove the booking reservation. If the answer is yes, the database checks to see if the user actually has the time, and if the answer is yes, it deletes the information from the database. If the answer is no or if the booking has been deleted, the member, in both instances, will be taken back to the reservation screen.