Getting Started on Your Application

When many developers get a new project to work on, their first instinct is usually to start coding right away. It's easy to understand why. Those first few hours or days of coding can be a lot of fun. The "inner geek" in each of us gets a special thrill from sinking our teeth into a new project, watching an application take shape, and carving something unique and useful out of thin air. Plus, there's often a deadline looming, so it seems best to start writing code as soon as humanly possible.

The problem is that even the simplest applications have a way of becoming much more complicated than they seemed at first. Nine times out of ten, if you take the time to plan your application and development process right from the start, you will do a better job in less time. Of course, people say that about almost everything in life. But in Web application development, it really is true.

Admit it! Your inner geek is already telling you to skip this chapter and get on with the coding. Resist the geek, if you can. The advice in this chapter will mean a bit more work for you up front. You might find that you even need to write a few documents. But you probably will end up doing more cool stuff and less tedious work if you know exactly where your application is headed at all times. Really. Seriously. Honest. Your inner geek might even buy you a drink when you're done.

Defining the Project

The first thing to do is to ensure that the project is as completely defined as possible. You need to know exactly what type of application to build, and that usually means doing some research and asking lots of questions.

In a perfect world, you would already have a written description of the application that defines its every aspect. You would know exactly what the expectations are for the project, and who will be testing it, using it, and benefiting from it. You would have complete understanding of every aspect of the project, from what technologies should be used to how the database should look.

In reality, you might have only a short description, such as, "We want to personalize our online store," or, "We need an accounting section in the company intranet." Sounds great, but you can't exactly start working yet.

The Importance of Being Inspired

If you can, try to have a vision about the project early on. Make it ambitious. Figure out how people are thinking about the project, and try to come up with some twist or feature that takes it to a whole new levelsomething an end user would be happy to see, and that you would be proud to implement. Why? Because it's important for you to be as interested in the project as you can be. If you're having fun during the development process, the application will turn out better. If at first the application sounds like something you've done or seen a million times before, try to think of something to add to make it unique. Even if the project already sounds difficult or daunting, think of some way to make it even more of a challenge.

Then, after you've gotten yourself excited about the project, try to get everyone else excited about it, too. Come up with a trademark-like name or code name for the project (perhaps from a favorite movie or a play on words based on the name of your competition). Talk about the project as if it were the cure for all diseases, as if it were going to save the world. Sell the thing. Even if it's filled with irony, your enthusiasm will bubble over onto the next desk or into the next room. At the very least, the project will be a little bit more fun. And how can that not be a good thing?

Understanding the Project

Now that you're enthused about the project, you need to get yourself educated as well. Before going further, be sure you know the answers to these questions:

• Internet, intranet, or extranet? Most projects will fall into one of these categories. Be sure you know which one yours falls into, and why. It is usually obvious that a project is an Internet project because it targets end users. Sometimes the difference between intranets and extranets can be more subtle, especially if the application is meant to be used by your company's business partners as well as in house. Even though it's just a word, be sure you and your client (or boss) agree on the word.

• Totally new or "Version 2.0?" You should know whether you are replacing an existing Web application. If so, why? What exactly is wrong with the current one? To what extent should you be using the existing application as a guide? Is the original just showing its age, or was it a total disaster from its very conception?

• New process or existing process? You should know whether your application is creating something totally new ("We have never had anything in place to do this"), or a modification of a current process ("We have always done this, but it was partly on paper and partly in a spreadsheet").

• Integrating with existing site? You should know whether your application is going to sit within the context of a larger Web site. If so, how will people get to your part of the site? How will they get back? Do you need to keep the navigation consistent?

• Integrating with other systems? Does any back-end or legacy integration need to be done? Perhaps your application needs to receive periodic updates from some type of batch process that occurs within the organization. If so, learn as much about the existing systems as you can. Also, find out if the project calls for the use of any Web Services that are currently available or are in the progress of being built. ColdFusion makes it easy to use ("consume") functionality provided by Web Services.

• Existing database schemas? Often, there is some type of existing database that at least part of your application will need to be aware of. Perhaps a table of customers and their IDs already exists somewhere in the organization. Find out whether your application can add tables and columns to this database or whether it should have its own database. Remember that ColdFusion generally has no problem dealing with information from multiple databases.

Conducting a Few Interviews

We recommend that you conduct a few informal interviews among the people who might actually be using your application when it's completed. Depending on the project, that might mean people within the company or potential end users on the street. Ask these people what they would like to see in the application. How could it be even more useful to them?

NOTE

A fun question to ask is, "If there were only a single button to click in this new application, what should it be?" At first, you might get sarcastic answers, such as, "It should find me a better husband," or "It should do my job for me," but you'll also get serious answers that can be quite telling.

These potential users will likely tell you more about how your application will actually be used than your normal contacts within the company can. They often are more likely to be able to describe what they need in ordinary terms. You might find that you think about the project differently after a couple of these short interviews, and you may end up reevaluating the importance of various features.

TIP

If your application is meant to replace or improve a process that these people perform manually or with an existing application, you might want to observe them doing their jobs for a short time. You might find that users spend most of their time doing task X, while you intended the application to assist primarily with task Y.

This interview process serves another, more subtle purpose as well. It associates a real persona face, or several faceswith the project for you. When you reach a stumbling block later, or when you design a form, you can have these people in mind. Perhaps without totally realizing it, you will actually be creating the application for these people. When it's finished, you are likely to have improved their day-to-day work experiences or somehow made things more fun or easier for people using your application at home. You'll find it more rewarding, and your application will have much more perceived value.

Setting Expectations

This is perhaps the most important thing to nail down as early as possible. Even the savviest people have a way of expecting things from an application that they never told you about. Setting appropriate expectations is perhaps the most important thing to nail down as early as possible in the process.

Discussing the finer points of the project with your client can go a long way toward establishing reasonable expectations. Keep in mind that many of these items are matters of give and take. You might frame the discussion by clearly defining the choices: "The upside of doing this would be X, but the downside would be Y." Consider:

• Modem users. If you're lucky, you're building an intranet that will never be used out side the local network. If not, you probably have to consider the poor folks connecting at 56K. Try to define an expected level of service for modem users (perhaps the first page must come up in 15 seconds or less and all other pages in 10 seconds or less). Depending on to whom you are talking, talking in terms of image size (no more than 50 KB of images per page) might be easier than talking in terms of download time. It's often best to talk in terms of file size with graphic artists and in terms of download time with everyone else.

• Screen resolution and color depth. Most developers and graphic artists have great computer monitors that display lots of pixels at a time. But many people use monitors that have only 800 x 600 or even 640 x 480 screen resolution. If those people are important to you but the current design calls for a luxurious, cinematic layout that uses a lot of horizontal space, it's helpful to point out that some people are going to have to use the scroll bar at the bottom of the browser window to see all elements on the page.

• The importance of security. You should know to what extent your application needs to be secure. Many applications need some level of security (based on a password of some kind, as discussed in Chapter 21, "Securing Your Applications"), but do they need more? Should the pages be further secured using HTTPS and SSL, or restricted according to IP address? Or should it be secured even further, using client certificates? Where will the application reside in relation to the company's firewall, assuming the company has one?

• Concurrent Users. If your client is thinking about the application getting a million hits per minute, but you have only an old 486 computer to use to host the thing, that could be a problem. Of course, ColdFusion's multiple deployment options make it inherently scalable, and you could always use a cluster of better servers later, but it can't hurt to ensure that you and your client agree on load expectations.

• Browser compatibility. Does the application need to be capable of looking great with every browser ever made, from the first beta of Netscape Navigator to the latest service pack for Internet Explorer? Probably not. But you do need to determine exactly what the expectations are. Point out that if you are using client-side features, such as JavaScript or Dynamic HTML, the more browsers you need to support, and the more testing you might need to do. Note that using Macromedia Flash in place of DHTML can go a long way toward avoiding browser compatibility issues.

• Platform. Unfortunately, today's Web browsers often display the same page differently on Macs and Windows machines. If you need to support only one platform (you're building an intranet for a strictly Linux shop, for example), your job might be a lot easier. Again, just be sure you and your client agree on what's expected.

Knowing the Players

Unless you are producing every aspect of the application on your ownincluding artwork, testing, and deploymentyou need to know who is going to be working on the various aspects of the project. Depending on the circumstances, you might need to assemble a team on your own.

A team usually consists of the following basic positions. Even if one person performs more than one function, be sure you know who is who:

• ColdFusion Coders. How many people will program the application? Just you, or a team of 20? Are the coders all under your control, or do they have their own chains of command or other responsibilities?

• Graphic Artists. Who will provide graphics, banners, and buttons? Who will design the overall look and feel of the application? Who will design the site's navigation and structure?

• Database People. Who will determine the new database structure or make changes to any existing databases? Does that person see himself as a developer (designing tables for applications and so on), or more of a database administrator (tuning the database, adjusting indexes, scheduling maintenance, and the like)?

• Project Managers. Who will ensure that the various elements of the project are completed on time and meeting all requirements? Who will keep an eye on everyone's schedules? Who will that person report to within the company? Who will report to that person within your team?

Fact Finding

Next, it's time to do a bit of research. This might sound like a lot of work, but the truth is you can often do the research suggested here in a couple of hours. It is almost always time well spent.

Looking at Similar Sites

Spend some time searching the Internet for sites that are similar to your project. Even if you can't find a Web site that does the exact same thing as the application you're building, at least try to find a few sites that are in the same conceptual space or that have pages that present the same type of information that your application will present.

For example, say one of your pages is going to be an "Advanced Search" page and another will present data in rows and columns. Find the best examples you can of such pages. What do you like about them? What don't you like? How does the use of color or spacing affect your opinion of the existing pages? When do the best sites use a button instead of a link, and why? When do graphics help, and when do they just get in the way?

Decide Which Technologies to Use

You also should research and decide which technologies you will use. Most likely, ColdFusion will give you most of the functionality you need, but you still need to answer a few questions:

• What's the database? Assuming your application requires a database of some kind, you need to decide which type of relational database system (RDBMS) you will use. Many smaller Web applications are built using Access (.mdb) tables or delimited text files as their information stores, and there is nothing wrong with this for smaller applications. Most people will advise you to consider a server-based database product (such as Oracle, MySQL, or Microsoft's SQLServer) for larger-scale applications.

• Any scripting or Dynamic HTML? ColdFusion makes all its decisions on the server side, just before a page is delivered to the browser. Sometimes your application will benefit from some type of client-side scripting using JavaScript or perhaps Dynamic HTML. If so, decide where you will use scripting, and to what end.

• Any Flash, video, or other multimedia? Depending on the project, you might need to include dynamic, interactive content such as Macromedia Flash movies, Shockwave presentations, or 3D worlds in your pages. These days, most computers are already equipped with the Flash player; with the Flash 6 player you can also deliver sound and video without an additional plug-in. Other types of multimedia content may require a plug-in installed on each user's browser. Such plug-ins generally can be installed automatically for Internet Explorer users (especially under Windows) but usually they must be downloaded and installed manually for other browsers and platforms. Keep these issues in mind as you discuss the project.

• Any custom tags, user-defined functions (UDFs), or ColdFusion Components (CFCs)? You should decide whether you will build reusable items while you construct your application. If you will, you might want to sketch out what each custom tag, UDF, or CFC will do and what each tag's attributes might be. (CFML custom tags and CFCs are discussed in Chapter 23, "Building Reusable Components." UDFs are discussed in Chapter 22, "Building User-Defined Functions.")

• Any custom-built extensions? Depending on the situation, you might want (or need) to code certain parts of your application using a different programming language, such as C++, Java, or Visual Basic. For example, you might compile a CFX tag to use within your ColdFusion templates. Or, you might create a COM object, servlet, or Java class, which you can also invoke within your ColdFusion template code. These subjects are not discussed in this book, but they are discussed in great detail in our companion book, Advanced ColdFusion MX 7 Application Development (Macromedia Press, ISBN: 0-321-29269-3).

Investigating Existing Custom Tags, UDFs, and ColdFusion Components

The ColdFusion Developer's Exchange site is a great place to look for existing Custom Tags, UDFs, or ColdFusion Components that might help you build your application more quickly. Using these prebuilt extensions to ColdFusion often enables you to get your application finished more easily. Why reinvent the wheel if someone else has already done the work and is willing to share it with you for free (or for a nominal charge)?

The Developer's Exchange is located at http://www.macromedia.com/cfusion/exchange/index.cfm.

The Common Function Library Project (http://www.cflib.org) is an excellent resource for UDFs. CFCZone (http://www.cfczone.org) is a repository of ColdFusion Components.

Searching the ColdFusion Forums

Another good place to go during the planning phase is the Online Support Forums for ColdFusion, where users discuss problems and answer questions for each other. Support engineers from Macromedia also participate in the forum discussions.

Try running searches for the type of application you are building or, for specific features you might not have fully formed in your mind yet. It's likely you'll find message threads that discuss various approaches of displaying the type of information you need to present, as well as any pitfalls or gotchas to keep in mind. You'll probably find code snippets and examples you can adapt as well.

The ColdFusion Support Forums are located at http://webforums.macromedia.com/coldfusion.

Investigating Standard or Third-Party Extensions

As mentioned, ColdFusion can invoke and communicate with Java classes and ActiveX objects. ColdFusion can also invoke and communicate with Web Services. You don't have to write Java, C++, or Visual Basic code to use these items; instead, you use them through CFML's createObject() function or through the <cfobject> tag. The basic idea is the same as when using Custom Tags: Why reinvent the wheel when someone has already done the work for you?

Therefore, it is worth a quick look on the Internet to see whether third-party Web Services, Java classes, or ActiveX controls are available to help with some part of the functionality your application is meant to provide:

• Java classes. It is also worth checking for Java classes that could provide specific chunks of functionality you need. For example, if you need a platform-agnostic way to deal with reading the public keys associated with a server's SSL certificate, you could take a look at the classes provided by the java.security.cert package in the standard Java Development Kit (JDK) from http://www.javasoft.com. Of course, you could look beyond the JDK as well; a great number of third-party products can be invoked through Java, which generally means you can invoke them via ColdFusion.

• Third-party ActiveX Controls. With only a few exceptions, any nonvisual ActiveX control (also known as a COM Object) can be used with ColdFusion. A good way to look for these items is to consult the components sections of the various Active Server Pages sites out therejust about any COM/ActiveX object marketed to ASP developers can be used in your ColdFusion templates. Of course, these components can be used only if you are using ColdFusion under Windows. For more on this topic, check out http://www.cfcomet.com.

• Third-party Web Services. As of this writing, Web Services are really coming into their own as another way of integrating other people's work into your own application. Instead of installing something on your ColdFusion server, you simply access the information exposed by the Web Service over the Internet. Nearly all Web Services can be used via a simple call to the <cfinvoke> tag or the createObject() function.

NOTE

A complete discussion of how to use these objects in your ColdFusion templates is beyond the scope of this book. See Advanced Macromedia ColdFusion MX 7 Application Development (Macromedia Press, ISBN: 0-321-29269-3) for complete explanations and examples. Also see Appendix B, "ColdFusion Tag Reference," to learn more about the <cfobject> and <cfinvoke> tag, and Appendix C, "ColdFusion Function Reference," to learn about the CreateObject() function.