4.2. Overall Structure and Files
Let's begin by looking at the overall directory structure and the files involved in this application. By and large it's similar to the project in the previous chapter, and it's very similar to all the applications to come. Figure 4-3 shows the directory structure.
Figure 4.3. The application's directory structure and constituent files
In the root directory we have index.htm, the starting point for the application. The css directory contains the style sheet, styles.css, specific to this application. The ext directory is where Ext JS itself is—I haven't expanded it because it's rather large and at this point you should be fairly familiar with its contents. The img directory contains a bunch of images used in the application. The files project.gif, resource.gif, and task.gif are the icons seen in the tree views. The file welcome.gif is the image seen on the welcome screen. The remaining images, the ones beginning with status, are the status icons seen on the various summary views. Three types are present: the green check mark (representing under the allocated hours), the yellow warning sign (10 percent of allocated hours remaining), and the red stop sign (over the allocated hours). Each icon also has a version that has "PastDue" added to the end. These are the same icons but are animated GIFs so that the icon flashes to indicate the item is past due.
In the js directory are all our JavaScript files. In this application I've taken a fundamentally different approach than in the previous project. Recall in that project that there was a single monolithic JavaScript file (plus the DAO class in a separate file, but the majority of the code was in a single file). You'll also recall there that to build the UI I used a single huge JavaScript statement. This is far from the only way you can structure your code with Ext JS, and in this project we see another. Here, each of the unique UI objects is in its own file. The menu code is in menu.js, the code for the New Project dialog is in NewProjectDialog.js, the code for the projects tree is in ProjectsTree.js, and so on. We also find a TimekeeperExt.js file that contains some more general code that the application uses. As was the case with the previous project, there is also a DAO.js file where the database access code lives. The familiar gears_init.js file is also present.
NOTE
Which architecture you prefer is largely a matter of personal preference. Some argue that breaking up the code like this makes it easier to comprehend, while others argue that the mental gymnastics of jumping between multiple files negates that benefit. I personally have mixed feelings, so I generally try for a mixed solution: I tend to break things up to a certain extent, but I don't go overboard making things too granular. What you decide to do is neither right nor wrong—it's simply a design decision you have to make. I felt it was important to demonstrate both approaches in this book.