The biggest mistake one could make when building a dynamic site is to make it up as you go along. This is a guaranteed prescription for failure because inevitably you will omit a crucial step or overlook a critical piece of information. This why it is so important that you "think through" the plan before constructing the application. For example, a simple procedure, such as booking a baseball diamond at Oakbridge, is actually quite complex. When the user hits that part of the site, he or she has to make some decisions. The first one is to choose when the diamond is available. When that is determined, the user can reserve the diamond using their membership number, providing the user is a current member. On the surface, that is a rather simple request. However, a lot goes on behind the scenes. Here are the basic steps:
Putting together something that accommodates those four simple steps requires the developer to do two things: plan the data and illustrate the logic. Note Don't laugh at Excel. You can actually select all of the cells in an Excel spreadsheet and drag and drop them into an open Dreamweaver MX 2004 page. When you release the mouse, all of the cells dropped into Dreamweaver are contained in a Dreamweaver table on the page. Data PlanningA data plan creates the blueprint that is required for the data model. Although it sounds rather technical, this document is nothing more than a list of tables and fields that will be used to store the data. If you have a database designer on your team, he will most likely refer to this document as a data dictionary . A number of ways exist to create this document, but, from our experience, one of the easiest is to either create a spreadsheet or use a table in a database to create the data dictionary, as shown in Figure 4.1. You will find a PDF template of the data dictionary model, Data Dictionary Template.pdf, on the book's web site. Feel free to download it and use it for entering your tables and fields in a database. Figure 4.1. A sample data dictionary that can be used to plan the data.
The data dictionary should contain the following:
After you have your tables and fields listed, create a model, or schema , of your database. The schema will show the tables in the database and their relationships to the other tables in the database. This way, you can see how everything works together. To create a schema in Freehand MX and to learn how to use a new toolthe Connector toolintroduced in Freehand MX, follow these steps:
Using the Freehand MX Connector ToolWhen the MX Studio was released to the market in late 2002, Freehand was included. Though the inclusion of Freehand in the Studio wasn't a surprise, it was surprising that the product did not contain the "MX" brand. This was remedied in early 2003, when Macromedia released Freehand MX to incorporate the panel-based MX interface. One of the more interesting tools was one with the odd name of the "Connector" tool. There really wasn't anything remarkable about it until developers discovered that, once again, Macromedia had been listening to its users and watching them work. When we create these schema, we have to connect the boxes to each other to illustrate data flow. This was both a repetitive and time-consuming task. The Connector tool removes that tedium from workflow because it enables developers to map information architecture, data flows, and site maps and to assign relationships between objects on the page. The key to using the tool is to understand that it establishes the relationships between the objects and that the look of the lines is controlled through the Stroke panel. To use the Connector tool, follow these steps:
The lines connecting the field boxes are, for lack of a better analogy, connected to the boxes. For example, if you want to remove a line, select it and press the delete key. You cannot, however, move the lines. If you do, the data boxes to which they are connected will move with them. To see what we mean:
Note Do not use the connect tool for database schemas because relationships have been within specific fields between tables and not tables themselves . If you are connecting fields, use simple strokes with arrowheads pointing to specified fields. A workaround to use the Connector tool for a schema is making a box for each field and then a separate box for the table that contains the field boxes. Now that we know how the data flows, we have to illustrate the logic using a flow chart . What Is a Flow Chart?To answer that question, you have to first ask another: What is logic? In extremely basic terms, it is the ordered sequence of steps required to get from point A to point B. Booking a tennis court at the community center looks simple, but everything in a web application requires a number of steps to achieve a certain task. For example, a user may be required to press a button to book the tennis courts. On the surface, this is a simple process, but the logic behind it includes checking if the court is available and, if it is, booking the court and sending a confirmation. The best way to show this logic is with a flow chart. Why Use a Flow Chart?Think of a flow chart as being the road map for the logic. Building dynamic sites is a complicated process, and you simply can't keep every step in your head until you start building the site. This is especially true when working in a team-based environment; a flow chart shows everyone involved what they need to know, and it underscores the requirements of the task at hand. As we pointed out earlier, booking a simple baseball diamond requires a four-step process that enables the user to choose the baseball diamond, choose the date, see if it is available, and make the reservation based on a membership number. A flow chart, as shown in Figure 4.7, presents everyone with a visual representation of the process. It is also a relatively simple process and is flexible enough that the charts can be combined to illustrate the entire process. Figure 4.7. A flow chart created in Freehand MX demonstrates the steps necessary to provide a user with a baseball diamond reservation.
Although the process of mapping out the logic may appear tedious and a huge imposition on your time, there are three solid advantages behind this step:
Flow Chart SymbolsAlthough we can use many types of symbols in a flow chart, we will use the four basic symbols, shown in Figure 4.8, for our purposes. Copies of the Fireworks MX 2004 and Freehand MX files, named LogicSymbols.png and LogicSymbols.fh11, are located in the Chapter 4 Exercise folder of the book's web site. Figure 4.8. The basic shapes used to create a logic map in Freehand or Fireworks.
The basic symbols are:
In Figure 4.7, we showed you a typical login sequence. This map is fairly typical of the work produced by developers. Unfortunately, even though the map looks impressive, there are some serious problems. The first is that the steps are terribly confusing. They can make life difficult for the database designer and the coder because it is hard to tell which steps are programming steps and which are decision-making steps. The second issue is the improper use of boxes. Using our shapes as a guide, the map is composed of procedures, which is not useful if your job is to build the database or do the coding. Finally, it is hard to tell where we enter and exit our logic. This chart will impress the client, but it is too complex. There are many steps that can be consolidated. Remember, the best way of dealing with complexity is from a position of simplicity. Figure 4.9 shows how we simplified the logic. Figure 4.9. Simplifying a logic map makes life easier for everyone, from the client to the database programmer.
When the chart is simplified, the steps become clearer and more understandable. The logic is also quite concise and easy to follow. Most important of all, the use of decision diamonds and terminal points to mark where we enter and exit this piece of logic suddenly makes life easy for all concerned . |