I love emails like this, they remind me that not everyone out there doing church websites has paid for the pleasure of having a nice, but somewhat nutty professor ram C.J.Date’s “An Introduction to Database Systems” in one ear and out the other until I could de-normalize data to the fifth level in my sleep:
A few weeks ago I fell into the middle of your site and have been soaking up all i can. I’ve read The Book and a year and a half of your archives. One concept that’s geekin’ me out is that of a data-driven site. Huh? I never heard o’ dat.
What -in all plainess- is it, and when is it appropriate/necessary? My hunch is that i don’t know enough to need it yet, but hey, maybe you’re gonna revolutionize my notepad-html routine. If not, it would at least be cool to have an idea of what’s flying over my head.
Anyway, good job, man. You’re inspiring techpentace. I take comfort in that.
Peace of Christ to you,
Emails like the one above are as flattering as they are also a convicting. One one hand, such messages assure me that my graduate studies weren’t a total of waste of time and money. On the other hand, such letters remind me of those times I neglect my mission to make the difficult concepts of computer science easy for those of you whose expertise is in other fields, but are likewise called to design and maintain the websites for your favorite churches and charities.
The above note from is a AlaskanAficionado is a good example of this. That is, while I’ve mentioned data-driven website design once or thrice, I’ve done so without taking the time to explain what a data-driven website is, when it’s useful and how it’s done. Massive mea culprits … for my penance, I’ve assigned myself a binary tree that I need to recurse using nothng but 80n86 assembler … but I digress.
What it is
At the risk of having my uber-geek credentials revoked, a data-driven website simply means that all of the pages on the website are created using a combination of boilerplates (a.k.a. templates) for the page layout, and a database or datafiles for the compelling content. If this explanation doesn’t help, then perhaps this oversimplified diagram will:
Think of it as water, two parts hydrogen (the boilerplates) and one part oxygen (the data) and viola, water.
When to use it
If your website is only going to be five pages of the same text forever to the same client application (e.g. your browser), then you don’t need a data-driven website.
If, however you are going to publish new and changing content on an ongoing basis, then you’re better off putting the content in a database and using some form of content management to publish your website.
Similarly, if you are going to take the same compelling content and display it in a variety of formats, then you’re better off using a data-driven approach.
How it’s done
Weblogs such as my site store content in a MySQL database. The boilerplates are comprised of a number of scripts written in the Perl programming language that include some database queries along with some templates defined by the manufacturer of the weblog software. The HTML pages you eventually read are physically created when the Perl programs are run through the Perl interpreter.
Website’s such as Mike Boyink’s relaunch of ParentPager.com also use a relational database, but use a programming language known as PHP as the boilerplate. Additionaly, the output HTML file is virtual; that is when you visit the site the web server runs the PHP file that extracts the necessary data from the database and delivers to your browser HTML on-the-fly.
Some people prefer WYSIWYG physical page creation using web-publishing tools such as Macromedia Dreamweaver and/or Microsoft FrontPage. In the case of the former, you’re ‘supposed’ to create a template page for your website (the boilerplate). Then whenever you need to create a new page, you use the template you’ve pre-defined – dumping data from your brain (the database) and resulting in an HTML file.
Finally, there is XSLT, which is short for Extensible Stylesheet Language Transformations and can be used to create both physical and/or virtual output. Basically the database is replaced with XML files. The boilerplates, XSL files. Then using a transformation engine/processor, the two files are used to produce human readable content – usually HTML. I offer an example of this in my June 24, 2004 post “Using XSLT to Transform the RSS 2.0 Daily Verse feed from the ESV Bible.”
1 + 2 = 3
So there you have it in a nutshell. By separating the compelling content into some form of storage, and by creating default layouts via program/scripts that use the data, you can:
- create dynamic sites on the fly,
- quickly back-up and restore data
- manage, categorize and manipulate content
- make content searchable
At least that’s why I do it. Here are some other related articles that also enumerate additional reasons why and how there might be a data-driven website in your future (or not):
- Gravity Switch – Should Your Web Site Be Data-driven?
- SitePoint – Build your own Database Driven Website using PHP & MySQL
- Anna Shin – The Benefits of Data-driven Web Sites
- Lasa KnowledgeBase – Database driven websites – an introduction
- Room 101: database-driven websites
- MSDE 2000 Walkthrough: Build a Data-Driven Website Using Visual C# .NET and the .NET Framework SDK
Oh, and leave a comment if you have any questions – or want to offer a clarification or additional reason for going data-driven – or not.