No doubt some of us have been involved in one or more projects in which we're acting as the developer or project manager/team lead and are responsible for creating the underlying directory structure for a Web site.

It doesn't matter if the site is on an intranet or Internet site, it still needs some sort of structure. In this article I present two possible ways to lay out the files for your site.

The wrong directory structure (from here on referred to simply as "structure") can cause minor or serious headaches down the road. You could end up with a site that requires numerous page changes every time you make any modification. Obviously that's not a very desirable outcome.

By using ColdFusion we can create a site with a great deal of flexibility and dynamic content control. We can use as few physical files as possible by rewriting the same template over and over again. The first example (Site A) uses a structure that doesn't lend itself to rapid site updates: numerous pages with identical content would have to be changed, which is less than ideal. The second (Site B) uses a structure I've implemented for the intranet at my office by leveraging a product by Ektron Inc. called EmPower (www. ektron.com), and some handy URL variable passing and checking. With this, you can have a dynamic and easy-to-maintain site.

In Site A we lay out the structure as illustrated in Figure 1. This design doesn't scream any terrible wrongs; however, let's go a little deeper. As you can see, the structure is broken down into departments, which sounds good at first. We definitely don't want the marketing and finance content to mix. We also have several folders under each department: CFML, images, docs, and includes. Basically this site has many templates that grab content from the includes folder. A marketing department page will grab body, sidebar and/or navigation content, and anything else the developer includes in the template he or she is creating. For each and every page in the marketing department section there's a template that sits in the CFML folder, as well as a main index file that's located at the root level of the marketing folder.

In Site B we'll take another ap-proach (see Figure 2). In this example we have a similar breakdown of the site. Each department has its own subfolder that contains folders for docs, images, and includes. I'm sure you noticed there's one folder missing - the CFML folder. The lack of this folder, as I'll explain in a moment, is what makes Site B much more developer-friendly. By friendly I mean that routine maintenance and content changes won't dominate the developer's day. This site works with a single template that resides at the root level of the site. This file contains ColdFusion code that reads URL variables that have been passed in via the URL string of the site. From these variables we can determine which includes folder to bring the content in from. In many cases these variables are numbers that correspond to database IDs of some sort, for example, "http://intranet/template.cfm?Doid=2&S1=a&S2=C&S3=NO". This URL tells Site B to go to the marketing subfolder (marketing has a Depart-mentOID [Doid] of 2), pull the S1 file "a", pull the S2 file C, and turn off the S3 section altogether to provide more room for S2. With just a few variables we've rewritten the entire page to suit our needs.

Let's go back to Site A for a more in-depth view of how this site functions. Site A incorporates a great deal of static pages (as static as any CFM page could be). First we have the index page that sits at the root level of each department's folder. This page is a template that calls files from the includes folder to build the final result, for example, "http://intranet/ marketing/index. cfm". For those not familiar with includes, ColdFusion has a tag called <CFINCLUDE> that will incorporate an outside file into your page at the exact point you place the <CFINCLUDE> tag. We have x number of templates in the CFML folder at each department level, for example, "http://intranet/marketing/cfml/somepage.cfm", and we have n number of department folders in this site. I say n because the number differs at each company. Each department may have only one or two pages; others, say human resources, may have 20. Keep in mind that some departments, such as HR, may have numerous forms and informational pages.

A little math shows how just making small changes could turn Site A into a very big and potentially costly (in developer hours) nightmare. Let's say we have n number of departments and x number of templates for each department, substitute a few numbers andŠ. For example, a company has 12 departments, each with an average of 10 pages on the intranet. Management has decided to remove the footer piece of code because it's no longer useful and the departments want that little bit of extra real estate. Now one poor developer will be on the hook modifying 120 identical templates just to remove a table row. I hope that developer isn't me. Clearly this isn't an appealing outlook. The more departments, the more possible templates you have. The problem can grow exponentially.

There's a pro to the Site A model - should your site have limited growth potential, then this would be the easiest to implement. The design and construction would be simpler since there wouldn't be any URL variables to capture and utilize. If your site isn't likely to grow past n number of departments, you don't have much to worry about in regard to future maintenance or modification issues.

Next we'll look at the footer change in Site B, which uses a dynamic content framework. We'll apply the same model company we used with Site A to Site B. Our company has 12 departments each with an average of 10 templates. To remove the table row that has our now defunct footer, include, we have only one file to modify (the one sitting at the root of our site). This is because we used some clever URL variable passing and a simple query to control dynamically the source content that goes into one template file.

The major con of the Site B model is that we have to manage the URL variables. New links to content within the site would have to be created by the development staff due to the need to pass specific variables with specific values. This is made a bit less difficult and dynamic by creating a list of the URL variables that can be passed instead of the individual ones. However, most departments have only one or two pages that they continually modify, so keeping an eye out for new links is a relatively light chore.

Conclusion
We've covered two types of site structure, static and dynamic. Since the future is unwritten, it's difficult to tell how much growth your site will experience. With that in mind, a model like Site B is probably your best bet for accommodating future growth, as long as you have the time to do the work up front. Site B has the most room for growth and the least amount of potential problems as the needs and layout of the site change. I'll leave you with this thought: imagine our model company with 12 departments and 10 pages per department. The CEO decides to completely change the layout of the entire site, and he wants it done quickly (which means yesterday). Which site would you like to be assigned to modify? Site A with its 120 pages or Site B with its one?

• Figure 1
• Figure 2