Heal Your Church WebSite

Teaching, rebuking, correcting & training in righteous web design.

Data Driven – what, when and how

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:

an oversimplified diagram of data driven web page production

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):

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.


  1. Not really related to data-driven concepts, but…

    “techpentace” sounds like such a cool word, but what exactly does it mean? Google and Dictionary.com are both ignorant of this word. I’d love to use it in a sentance of my own… :-D

  2. Some other benefits to data driven web sites:
    - Completely change how the site looks and feels without updating all of the data.
    - Manipulate what gets shown on the page dynamically (i.e. show only events for the next two days, only have 10 items of a list on each page, etc.)
    - Provide custom searches (search only music lyrics, only calendar events, only audio messages, etc.), instead of searching the whole site
    - Allow users to enter information instead of doing it yourself (i.e. secretary adds calendar events, people sign up for mailing lists, people can send prayer requests, etc.)
    - Can hide email addresses in fun ways with little work (putting contact ids in form submissions instead of email addresses, dynamically generating images of email addresses instead of using a standard mailto link, etc.).

    These are just the things that I’ve come across as being beneficial.

  3. DD sounds good… uniformity, maintenance, change management.

    What about search engine visibility? (IOW, how’s the search engine gonna see my compelling content nestled safely in a MySQL table?)

    I’m almost positive this has been addressed in the websphere, but I bring it up here…


  4. As far as Google (and other search engine crawl bots) are concerned, they see the pages just like your visitors do.

    My simple guess is that it visits your page (typically twice a month for most church sites, heavier traffic ones maybe more) and follows the links on the page at the time and caches that information. It doesn’t matter if those links are dynamically generated, it just looks at what the html shows.

  5. Another benefit of the data-driven website, if it’s done correctly: The time-strapped webmaster doesn’t have to update all the content al the time. That can be left to a less technically-minded but time-rich person :) I’ve employed a PHP/MySQL content management system called Xoops (www.xoops.org)to power our church’s website. It takes a bit of effort/CSS & HTML knowledge if you want to truly customise it to look the way you want (although there are lots of “themes” available for use)but once it looks the way you want, updating it is a snap.
    (Yes, i’m a Xoops convert, but there are plenty of other Content Management Systems out there)

    Great site, i’ll have to spend some time reading your articles.

  6. hey – that cj dats DB book is still the best one out there :) – don’t knock it!

  7. Frank, as far as search engines go you can always use ModRewrite if your on Apache (i.e. contactform.shtml?contactID=1 can turn into contactform_contactID1.html) and compliments browsers and search engines just fine. Additionally, it makes a lot more sense for users (you never know if they keep close watch on the length of the URL!)

    I find database-driven sites can save a lot of effort but they only do so through a lot of careful fore-planning and a lot of grunt work before actually released. For example, I designed a sermon system for a church that allows the pastor to update/add his sermons easily from MS Word, but it certainly isn’t going to be easy if I want to change the database now! You can view the system at http://pvcc.cbcregina.ca/sermons/ — see? Databases are cool when well thought out and designed. Happy coding!

  8. good timing – i have a meeting tonight to discuss the next (long awaited) plan for the church website, http://www.wheelockheathbaptist.org and I want to go to a CMS – I’m looking at mambo but it might be too complicated. Unfortunately i’m sure they’ll want something up by tomorrow ;-)

  9. We use blogger for our sermons website. Not sure if that would qualify as data driven because of course the html is formatted by Blogger. We plan to improve the look of the pages and of course it will be really easy to do so once they are all published in the same way.

  10. Techpentance: An intentional, dramatic turn from ignorant and/or abusive misuse of technology to the beneficial and wise application thereof.

    Dean, Thanks for the great reply.

    Peace of christ to you all.