As I touched on in my post about keeping your code clean, there’s more to coding than just writing good code. It’s also about organizing your scripts efficiently. Here’s my method of organizing scripts.

(source)

I started using this method a few months ago. It isn’t perfect, but it works for fairly small web applications that I build on the fly.

Directory Structure

My directory structure looks like this:

Here’s a brief rundown of what goes in each directory:

1. styles/ – Everything frontend goes here. Nothing is at the root of the directory usually, only in subfolders.
   1. styles/css/ – Fairly self explanatory, all of the CSS files go here.
   2. styles/img/ – Again, fairly self explanatory, all of the images go here.
2. support/ – Everything backend goes here. Nothing is at the root of the directory usually, only in subfolders.
   1. support/ajax/ – Any scripts that are accessed via AJAX are put here. I like to segregate these from other scripts so that they all have similar include patterns. They will require files from the support/config/ directory, so I may have a script that includes all of these files and then is included by one of the scripts that is directly accessed via AJAX.
   2. support/config/ – All and any configuration files go here.
   3. support/element/ – This is where all of the individual page elements go. I’ll talk about these a little bit more later. This is pretty much the area where front end meets backend.
   4. support/includes/ – This is where all of the ‘support’ scripts go. These will be scripts containing functions or classes that are used by the page element scripts.
   5. support/js/ – The JavaScript files are found here. In my opinion, this could go in either spot. If you look at the organization as styles vs support, as the directory names suggest, this would go in the support folder. If you look at it as frontend vs backend, it would go in the frontend folder. Put it wherever you think it should go.
3. index.php – This script handles all incoming requests. Using Apache’s mod_rewrite, I rewrite all URLs to point to this script. All of the information about the page being accessed is transformed in $_GET variables by mod_rewrite.

Index.php – The Handler

Here’s an example of what index.php may look like:

<?php

	require_once( 'support/config/general.php' );
	// (other configuration and includes scripts are required here)

	$controller = $_GET['cont'];
	$action = $_GET['act'];
	$argument = $_GET['arg'];

	if( empty( $controller ) ) {
		require_once( 'support/elements/home.php' );
	} elseif( $controller == 'users' ) {
		require_once( 'support/elements/users.php' );
	} elseif( $controller == 'extras' ) {
		require_once( 'support/elements/extras.php' );
	}
?>

This script does all of the core includes and sets things up for the next script. Then, it sets up all of the variables that determine what is displayed. I split up every request into three parts: the controller, action, and argument. The controller and action are required for all requests. If either do not appear, they are usually assumed to be home and index, respectfully. The argument is optional. These three variables can describe just about any request that is made. Trying to view someone’s user profile? The controller would be users, the action would be profile, and the argument would the id of the user that you’re trying to view. Trying to post a topic? The controller would be forums, the action would be newtopic, and the argument would be the parent forum that you are trying to post under.

Index.php decides which element (all of the elements are essentially controllers) and then includes the necessary files. When the element script takes over from there, it determines what to do according to the action and argument.

Why I Like This System

I find that this system simplifies the process. Every directory has a certain type of scripts or files that it contains. All of these scripts or files have the same purpose. I believe that the directories are set up logically while still keeping it simple. This could be a lot more complicated, but it doesn’t have to be. It isn’t designed to be used for large scale web applications, only medium to small ones.

Things are extremely easy to debug when using this system. If there is a problem with a certain module, I can open up the controller script for that module and see what the problem is. As long as global functions (in the includes/ directory) are kept simple, and don’t do a larger job than they have to, things can pretty much only go wrong with each individual module.

What’s your method of organizing projects? Do you like my method? Please leave a comment!