Iteration 1 : The Code
The Code Viewer
My journey into Object Oriented Programming (OOP) and ColdFusion is a programmatic adventure. That means the fun is in the meat of it, not just the start and the end. Come along with me people. You can't just sit there and wait for iteration after iteration to be finished. You have to be in the trenches, learning with me. This code viewer allows you to look at my progress on this project on a day-by-day basis. See how I am updating individual files. See where new methodologies are getting applied. See how OOP can help you.
Note: The code viewer works better in FireFox (big suprise), but is functional in both FireFox and IE.
The Application
For every code update, I will update the live application. The live application will always have the most recently updated code. Click here to launch the latest version of the application.
Iteration 1 : Code Updates
Download the updated code (ZIP file)
I have taken the Skin Spider site template and broken it out into a basic ColdFusion site structure for header and footer reuse. I have also created the Application.cfm page. I am going to wait until the next phase to implement the Application.cfc; I figure that's a "next" level type of thing. I am also going for very low-level storage. Right now, the only thing being persisted is the instance of the DatabaseService.cfc ColdFusion component. I am going to be calling that on almost every page and I don't want to have to keep re-creating it.
Every page will have to explicitly set the REQUEST.Page value (ex. home, about, search). This is a variable that will let the headers and footers know how to render the site. For example, a page that sets REQUEST.Page to the value "home" will cause the "Home" tab of the primary navigation to be turned on (and the rest to be turned off).
Each section of the site has had a top-level "dummy" page put in place. I don't want anything to break. I would rather just see a "page in progress" type page than a ColdFusion error. I think this is part of agile programming, but I cannot be sure as I don't really know about that stuff.
As I just stated, every page has its own top-level CFM file. There is no front controller (an index.cfm page that is always called to determine how to render the page and what files to include). I think most people go with top-level pages at first so I want to go that route for now. In the next phase I will probably move to an index.cfm type front controller, but that will have to wait till then.
If you look in the Application.cfm page, I cover how to do basic application initialization. I talk about why double-check locking is sometimes important when it comes to mission critical race conditions. I have also outlined the schema for the first few data tables that will be used to initialize the DatabaseService.cfc ColdFusion component.
As part of the pre-page processing, I am also unioning the URL and FORM structures (REQUEST.Attributes). Most of you have probably seen something like this in FuseBox and a number of other frameworks. The beauty of this is that you can explicitly scope a variable without have to know which scope it originally came from.
You will also see that as I am adding the FORM scope to the REQUEST.Attributes structure, I am looping over it and preforming some basic manipulation. For one thing, I am trimming all values in the form. I never want to have extra white space. Doing it here allows me to not have to worry about it when I am doing form processing on individual action pages. I am also unescaping any quotes. I have been doing this for so long, I can't be 100% sure, but I believe that form fields automatically escape entered quotes to be """. I don't want to store that value in any database, since it is not what was intended by the end user. Therefore I unescape them as part of pre-page processing. (NOTE: You will have to re-escape them if you put them back into a form field as the quote will BREAK THE HTML).
As I loop over the form fields I would also replace out things like the Microsoft Smart Quotes, but I don't see them being part of this application. But just a note, that this is a great place for any global form data manipulation.
I have broken the original CSS definitions into three separate files:
content.css
These are the style definitions for basic inline content. By that I mean things like headers, lists, paragraphs, link colors, block quotes, etc. It is basically all the generic content styling.
meta_content.css
These are the style definitions for page content that is NOT site structure, but is also not generic content. Things like data form layouts, or table grids. These are elements that are in the "content" but are much more highly formatted.
main.css
These are the style definitions for the site structure. Things like header, footer, site width, and primary navigation would go in here.
The order in which I include the CSS files is important. I include the content first and the site structure last. This allows the site structure to override styles that are set in the content. You might think that you would want the content to override the site structure definitions, but in my experience, this only leads to trouble.
Iteration One Updates
Oct 12, 06 Code Update
Oct 10, 06 Code Update
Oct 7, 06 Code Update
Oct 4, 06 Code Update
Oct 3, 06 Code Update
Oct 1, 06 Code Update
Sep 29, 06 Code Update
Sep 27, 06 Code Update
Sep 24, 06 Code Update
