I wanted to write an article that summarizes how a modern, small-scale website is built. There are articles out there that go through the principles and concepts of modern site building, but I think there needs to be an article that is based on example. I chose my own studio website as I thought it actually covers all the concepts, as well, technologically it touches on everything a modern website has: XHTML, CSS, JavaScript, PHP and MySQL. This article does assume an intermediate understanding of web designing and programming, so I will write accordingly, skipping the introductory.

Background

It was obvious over the summer of 2005 that my former website which mostly had work from grad school wasn’t an appropriate place to showcase all the work, whether commercial or non-commercial, that I’ve done in my first year out of school. At first I alloted myself one day to conceive, design, program and prepare my material; but obviously no matter how small, it’s nearly impossible to build a website from scratch in one day, at least one that will last longer than a day. Overall, this project took five days to complete, which in my opinion is rather good, considering it’s full featured and easily updatable. This of course is because I was my own boss and client, and lacked any sort of corporate bureaucracy.

I view the creation of a website to be similar to creating a GUI application or program; and just like creating an application, it is good to follow the Model-View-Controller (MVC) model. In the web context, the model is defined by XHTML, the view by CSS and the controller by JavaScript (and they can all be generated by some server-side programs.) The separation and distinction between these three distinct parts of a website is essential for building an effective, updatable website; and I will discuss each section separately.

Concept

Before you begin construction, you first need a concept. You need to give this website a reason for its existence. A meaningless website is just not worth creating. In this case, this step was rather simple. I wanted to have a website showcasing some of the work I’ve done in the past, another place to have articles that I’ve written as well as to have links to some code for general consumption. It was imperative that it was easy to insert, edit and maintain all the content.

Another more technical issue you need to deal at this stage is to decide on your audience. What is the target audience of the site? This information will help you guide through the design and development stages. It is also important at this stage to decide what browsers the site will support. I decided that I will only support modern, standards complaint browsers (Safari, Firefox, Opera and all of their variants) as well IE6 which will be supported by hacking up at the end.

Design

I decided early on that I want the site to resemble a “book.” The initial page will be a Table of Contents page which links to projects, articles, code, etc. I also decided that I wanted to guarantee myself that I will indeed update the site, which meant it really had to be easy to update. Because I am quite lazy, I knew each project can only contain one image. An image per project, that’s something I can handle.

If there was only one image per project, it didn’t make sense to link them from the front page. Instead, I came up with “marking” each project with a selection of categories, so that the viewer will browse through and choose a category they are interested in seeing. When browsing through these categories, one can browse to the next or previous projects, as well, there is an Index button that pulls down to reveal a list of links to all the projects within that category. Rather than page numbers, the links are URIs, which are interpreted using mod_rewrite. We will touch on that later.

Model

Like I’ve mentioned eariler, I am really lazy; and because of that I hate dealing with lots of files. The site required a design for the first (table of contents) page, a page for the projects and a page for the articles. I can’t deal with three html files, and so I instead used one php file to generate all three files. By using a GET variable, and a series of if/else statements, you can construct one php file that generates a specific page. Something along the lines of this (of course you should make appropriate security percautions.)

The only other thing to mention in the model section is to note that the html file just describes the structure of the site, and only links the CSS and JavaScript files.

View

There isn’t very much to talk about in the view section, except one thing. Do not get lazy and use the style attribute in a tag to apply a style (at least fields that are not structural.) Instead, make sure you use an external style sheet and specify IDs and classes to explicitly define their styles. Implementation is rather easy. You can use CSS triggers by specifying IDs and classes to apply the styles in the html file.

Controller

The controller is a little more complicated. This site makes use of a lot of JavaScript. In a way, it’s bad to rely on JavaScript to control navigational elements, since most browsers let the user disable it. If a user with JavaScript disabled comes to this site, they will only be able to see the first project on the site, and can’t see anything else. Knowing that, I still went with the JavaScript navigation, because I assumed the majority of the people who visit this site will not have disabled JavaScript, and if they did, it’s not completely essential that they see my site. Beyond the navigation, this site also uses JavaScript for image transistions (fade-in effect.)

Also in keeping with the whole idea of separation of the controller, all the scripts are written as an external file, and uses prototypes for easily usable code. I use MudFadeGallery and MudPopContent, which can easily be implemented on any other site. You can also deploy multiple instances in the same page, such as running two fade images. Finally, the initialization code is written as a php file, much like the html files; since the initialization varies between specific pages.

Most people are familiar with attaching event handlers to <a>, such as <a href="#" onclick="doSomething();">do something</a> but that goes against our separation principle. We can’t have any JavaScript in the html code. So how do we enable JavaScript triggers? This article on a list apart is a good place to start. When the initialization code is run (mud_Scripts.php), there is a function called setOnMouseClick() that first sniffs through all the <a> and checks the className of each one, like the following:

All you need in the model is <a href="#" class="doSomething">does something</a>, and remember to return false to prevent the browser from printing the # onto the URL. We just have to cover another topic before we finish off with the controller.

AJAX is the big hype of 2005 in the web technology world. In order for the images and captions to swap between projects without a page reload, we employ the asynchronous part of AJAX. But in this case, I really wanted to simplify things. Why bother making server calls when you can do all that stuff at initial load? We use the property innerHTML to swap out the captions and src property of img to swap the images. We could also use xml, but parsing xml is too much for a lazy programmer. Instead I construct an array that carries all the captions and image locations of the projects when the page is first loaded (via mud_Scripts.php). That’s the main reason mud_Scripts.php is a php file. Within the html file, we just need to make a placeholder <p id="proj_caption"></p> and using innerHTML will insert the caption in that location.

Content Management

Utilizing a database for a small site like this may be overkill, but since implementing MySQL is so easy and so useful, it doesn’t make sense not to use it. The information required in order to construct the array in mud_Scripts.php is all provided by the database. There is only one table and just a handful of fields which are:

• — id (auto incremented primary key)
• — name (full project name)
• — shortname (shortened name, used for image names)
• — image (image type: jpg/png/gif)
• — year (project year)
• — caption (caption text blob)
• — type (keywords that mark project)
• — public (toggle whether publicly visible)
• — sequence (used to manually reorder)

The public field is useful in that if I want to prevent a project from being publicly visible, I just have to set the value to 0. It’s also useful since the project still exists on the server, and I have it for archival purposes. There’s no need to delete it permanently.

Usually when I create a database, I like to use the command line MySQL client to run CREATE. For inserting or modifying current data, I use either phpMyAdmin or CocoaMySQL. Of course if this was a commercial project, I will probably build a small web interface for the client so they don’t need to use any complicated software.

URLs

Finally, the whole idea of using URLs as page numbers required me to have clean, well formed URLs. Normally, that will require hardcoding of many html files and requiring the need to create a file structure on the server. Instead, by using mod_rewite, we can take the requested URL information and transform it into query variables for the php files. For example: /projects/web/ will output: index.php?type=projects&filter=web

Conclusion

I hope this gives some understanding how modern websites using MVC model is constructed. I know it wasn’t too technically detailed, but the important thing was to explain the ideas behind the structure of this site. I wanted to make sure there are still reasons to tinker and hack the code yourself! But if there are requests for specific code samples, I will edit this article to include some.