Since 2008 I have been doing miscellaneous work for a client on an as-needed basis. My first job for him was a simple spreadsheet fix and it grew into other projects, the biggest of which was the company website. The site was originally just a plain white background with the company logo and a little background information along with contact information. I expanded the site to include pages for the individual product lines and added graphics. They wanted to make it more attractive but their design needs were beyond my expertise so they hired a company to build it, under my guidance and specifications. The resulting site is quite attractive but a little cumbersome to work with because the layout is based on tables and the menus are placed on each page making changes far more labor intensive than necessary. The host is a LINUX server and the site was purely HTML and CSS with no server-side coding at all.
In 2010 they wanted to add a feature that allows the user to click on an icon on a product page and have a new page open with a full specification sheet that they could then print. The sheet was to include a photo of the product, description and full specifications along with the companies contact information and logo. There were a couple ways to attack this request – one way would be to create a specification page for each of the items and hard-code a link which would have made a lot of money for me or we could do it the smart way and create one page using PHP and bind it to a database on the backend. This page would be built dynamically based upon the item the user clicked on. I suggested the latter and the client agreed so I went about learning PHP. I then discovered that the database available to me was PostgreSQL which I had never worked with. I was expecting MySQL, a database that I was familiar with. It didn’t take long for me to learn the necessary technologies, build the database and write the code; within a week of the initial request I had the work done. The company has added products since then and the update couldn’t be easier – or could it?
That brings me to the next step in the evolution of the site – ASP.NET. I have been wanting to bring the site over to .NET and SQL Server for a while but the clients host didn’t offer the service with the package they had and the advantages weren’t enough to warrant a move. It wasn’t until I added the ability to save customer contact requests to the database that we finally reached a point where the change was worthwhile. I added a couple tables to the database to store the contact request and comments from the sales department and created a PHP admin page where they could view all the requests and send e-mail to the customer. It is functional but it isn’t what I wanted to do. I spoke with my contact at the client, outlined my vision for what the site could be like and got the green light to migrate to .NET and SQL Server. They found a new host and had the existing site moved, all I had to do was build the database on the new server, add the data and update the connection strings. The host was capable of running both PHP and ASP.NET. The goal was to re-build the site so that it was completely data-driven and new items could be added simply by adding the information to the database. This means that when they add an 11×14 inch spiral bound notebook to the rest of the spiral bound notebooks (note: the client is not a stationary supply company, this product is for illustration purposes only) they only need to add one record to the database and the site will update automatically. If they want to add a completely new product line, I would still need to do some HTML work on the front-end. The new design would also allow them to sort the data on the contact request admin page, view all of the comments entered by the sales department and perform other routine maintenance of the data.
My first step, after deciding on C# as my development language, was to create a “master page” which will have all of the header, navigation and footer information on it. This will dramatically reduce the time required to add/remove a page, re-arrange the menu and update the copyright information. I now have one place to keep this information instead of more than a dozen. Once I had the master page it was just a matter of creating the home page, individual product pages, information request and administrative pages. I started by creating a template for the product pages to make the process more efficient. I was able to copy most of the content and much of the structure for each product and paste it into the new template with only minor adjustments. What I didn’t have to do was include the product specification tables under each product, those were now driven by the database. I simply had to set up an empty
<asp:Table>, give it a name and it was done. I created a stored procedure to retrieve the product data from the database and a class module to handle the data. Each product line is different and not all of the fields in the database table with have data so the code looks for fields in the returned recordset and only puts that data in the product table to present to the user. This allows me to use a single stored procedure and the same code for every product, current and future. By using a stored procedure to query the database I can make changes without having to update the source code in the pages. I have found that it is (almost) always best to run the queries from stored procedures within the database rather than in your source code. There are exceptions, of course, but it is a good rule to live by.
I think this is a good place to stop. In Part II I will cover the “Contact Us” page along with pages that handle site and data administration.
If you would like to know more about this project or have one you would like to discuss, please write to me at firstname.lastname@example.org.