Skin Spider : Basic Site Structure Completed
Posted September 27, 2006 at 2:09 PM by Ben Nadel
I have posted the second bout of coding for Skin Spider.
I have also posted the application. This application will be publicly available and will always contain the latest code posting.
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.
