Forgive the ‘pure geek’ nature of today’s post. I’ve been doing alot of late-night work Programming the Perl DBI to import a comma delimited file from the calendar associted with MS Outlook. People were complaining that the ‘old Redland Site’ was looking even more dated because I neglected to update the Calendar of Events with the re-write and all.
That said, it is not time wasted as most of the code will find its way into taking the same comma separated file from our Church Office and pushing into a MySQL table. Then pushing it back into HTML. Why this way and not some XML/XHTML coolness? Why the two-step process? Time. Actually Date and Time. The data came to me categorized by event description, not date/time – the database takes care of that for me w/out entering hash hell. Moreover, I can now ‘cron‘ a job to dump the data on a regular basis to keep the calendar looking fresh … so long as we have future dates in the database.
Since the import will occur with less frequency – that is, since the comma separated file will usually occur on a quarterly basis – and since I want to generate an up-to-date calendar for the current month, plus a week on either side of that, it makes sense to two-step this process. Even more sense to only cron the second part of the job – page generation. Good thing the old site uses server side includes for the ‘body’ of the text – in this case the actual dates!
Here are a few more links I found useful … and don’t worry, as always, I’ll post the code a bit later this week.”
- DBI: Chapter 5. Interacting with the Database
- WCUG – Perlweb – Reference Guide
- Perl DBI Examples
As I think on it, I’ll probably cron the job late Sunday/early Monday nights – 0 1 * * 1 – and since Christmas is coming, better include ALL of December. Yet another convenience of using a database in this situation. The code change is minimal – and could be data-driven if I really wanted to be slick.