Flexible Directory Structure
In my quest to become a better programmer, I am trying to learn Object-Oriented Programming (OOP). In that vein, I have started a book on Design Patterns ("Head First Design Patterns"). The first design principle that they cover is "Identify the aspects of your application that vary and separate them from what stays the same.".
Well, I am along way yet from being a good OO (Objected-Oriented) programmer, but this is - at least - is something that I have been doing. I have actually been using the principle (or some variation thereof) to guide the directory structure that I use for web sites.
My goal for my directory structure is actually that things should be grouped together based on when they are likely to change (since all things change, after all). Let's take a look.
The "/_bak" directory is relatively straightforward. The is a temporary storage location for files that I think that I should delete. I put them in the "/_bak" directory until I am certain.
The "/f" directory is for files uploaded by the site-owner, usually via the admin interface. I have a subdirectory for each type of information - typically one directory for each database table in which a record of the file is stored (though I intentionally do not name the directory the same as the table).
The "/i" directory is for images (that are not uploaded by the site-owner in the admin interface). Like the "f" directory, I do not put any files directly in the "i" directory.
The "/i/d" directory is for images that are part of the design (as opposed to images within the content). I number the directories within the "/i/d" directory by design revision. When the site is first created (the first design revision), all of the images needed for the design are placed in "/i/d/1". This would hold the site logo and any images that are part of the design of the site.
When the site is redesigned (it will happen someday), I create "/i/d/2" and place all of the images for the new design in that directory. Eventually I will be able to delete "/i/d/1". This allows me to easily know which files I can delete and which I cannot - less risk of a major build-up of unneeded files.
The "/i/en" directory holds any images that are not part of the design that contain words (assuming that they are in English). This allows me to easily create a new directory if I need to have more than one language on the site (for example an "sp" directory for Spanish). This is not much extra trouble if I don't ever need more than one language on the site, but saves me a lot of trouble if I do. If I have words in the images for the design itself, I create a directory under the design number for those files. You can find two-letter language code here: http://www.w3.org/WAI/ER/IG/ert/iso639.htm
The "/i/photos" directory is for any image that is not part of the design and doesn't have any words in that will need to be translated if the site needs to be multi-lingual (for example, the image might have a copyright notice, but no other text).
The "/lib" directory holds any JavaScript files or files supporting JavaScript files.
What about CSS files? Well, to be honest I am not yet as consistent as I would like with CSS files. In theory, I believe that they are part of the design and should therefore be in the in the directory for the design of which they are a part. In practice I sometimes put them in the root directory instead for convenience.
This directory structure allows me to easily accommodate common types of changes that might be faced by a site. Naturally, these won't be the only directories in a given site - each site will have directories specific to the needs of that site.
One quick aside, for those of you worried about extra characters. If you usually use an "/images" directory and are worried that this approach adds too many characters, consider this: "/images/" is 8 character; "/i/d/1/" is 7 character, "/i/photos/" is 10 (you could rename it "/i/pics/" and be back at 8).
I have found this approach to be helpful, hopefully you will as well. If you have any questions or suggestions, I would love to hear them - just leave me a comment!
Good luck!
There are no comments for this entry.
[Add Comment]