18 September 2006
Writing files at run time or by cron
For numerous reasons, not all content on the Internet can be dynamic. While I would personally love to see the Internet (and various Intranets) part of one gigantic library, all coded in PHP, that’s not feasible. Particularly in cases where content must be reviewed and approved before distributing it, static content leaves a nice trail of blame for mistakes. However, even in pages full of static content, there still needs to be some dynamic content— page headers, navigation and footers in particular. And this causes the need for the static/dynamic plague called an include.
To any programmer with even a single unit of skill will organize their project, with naming conventions, sub folders, and techniques like abstraction. It makes their project easier to maintain and also makes it easier to transition elsewhere. It takes a headache out of development. Yet most programmers, even experienced programmers whom I would otherwise tremendously respect do one thing I would classify as an obvious flaw: dumping every piece of dynamic static copy into an “includes” folder. The logic for this puzzles me.
For one, data is data. The fact an “include” happens to be consumed by another page is irrelevant. It is data and is being consumed. This is why I disagree with Rasmus on at least one topic in PHP security. But all this is really just the architect in me, wondering why the functionality isn’t correctly abstracted away.
But the topic I wanted to address in this article is how to best generate these “includes”. And there are really two ways:
- A dynamic program writes an updated include on every instance
- A cron job writes a a file on a set interval
I see absolutely no advantage to the cron job. They are both convoluted to maintain, but the write-on-edit behavior makes debugging easier and also keeps the include as integrated with the rest of the application as possible. Cron scripts don’t have to be separate from an application, but too often, they are. And their methods differ greatly as well. Some merely trigger a normal, web-accessible script to run. Some directly are a script. And some are even written in another language.
Cron has its place. Things like backups are best handled by Cron. But atomic actions like generating an include, adding a user, basically any action that can occur randomly are not well suited by Cron jobs. And for things like backups, I strongly feel like they should just trigger an application to run code. Cron is ultimately just a way to trigger an action, so its receptor should treat it as such.
And please! Lay your includes out in a logical way. You don’t lay SQL next to presentation in code so why do it in outputs? Yes, it’s all outputs, but so are Databases and Form Fields. If something must be escaped to be used, it’s an output. Keep all related files together.