| || |
Automated Website Maintenance
It's all about separating style from content. Crucial, that is. If you do that, then you can change the look of the whole site by changing one file, and you can edit your content with a minimum of presentation-related crud obscuring the view. You can also do arguably useful stuff like skinnable websites.
Of course, it's obvious from that blue border that style's not my thing, and there's not much content here either. I could say meta at this point, but honestly I feel less like a computer scientist every day and I can't be bothered.
If you want to know more about how I've done this, and you have a matrix account,
you can always poke around in
<a href="http://matrix.netsoc.tcd.ie" onMouseOver="window.status='Matrix, Netsoc\'s members\' server'; return true;" onMouseOut="window.status=''; return true;"> Matrix</a>
So instead, I use an m4 macro. When I edit my webpages,
I insert a link with
Here's another example: sometimes, a footnote seems like a worthwhile
thing to include, perhaps explaining what a bananafish is¹
hd_note([],[[What's a bananafish?]], [[Why, I've known some bananafish to swim into a banana hole and eat as many as seventy-eight bananas. hd_link([[http://www.geocities.com/Vienna/3597/A_Perfect_Day_For_Bananafish.html]], [[More about bananafish]],[[Is this abridged?]])]])
Such definition bits would make a great tool for educational websites; you could develop
a stylesheet that had an unobtrusive link class, and automatically add mouseover definitions for every
word in a glossary, so when someone is reading something and they've forgotten what MCMC
When doing a didactic bit like this, you don't want to have to go escaping your html every time you want to quote a macro; that's donkey work. So I have a macro to escape HTML as well. Other useful ones define a variable containing the contents of a file, and one to include an M4 file with out too much mangling (in fairness, m4 is not really meant for processing m4 files and confusion can easily result if you try to use it for same).
Here's an up-to-date view of the m4 file, globals.inc, that defines all those macros (included automatically using the hd_includeM4 macro). It may be worth bearing in mind that m4 is harder to read than it is to write.
The bottom of every page on this site has a comments area, powered by php. The php code that generates the message board is the same for every page. Similarly, the html that generates that blue border is the same for every page. So all the pages are generated from the same template. The template when the website was last made looked like this:
The template's pretty straightforward. First the file
The time is perhaps ripe for a big picture overview. Here's how the whole thing works: I write
a webpage with a
pages := $(patsubst %.webm4,%.php,$(wildcard *.webm4)) incs := template $(wildcard *.inc) website : $(pages) cp *.php *.css /home/hdenman/public_html/ %.php : %.webm4 $(incs) m4 -Dhd_content=$< -Dhd_title="$(shell head -1 $< | perl -ne 'm/\s*\<\s*[hH].+?\>(.+?)\</; print "$$1\n";')" < template > $@
Here's how it works. First, the line
File that end in .inc are files designed to be included in other files (another extension chosen arbitrarily).
The next bit is a makefile rule, that tells the make program how to make the thing called 'website'.
The final part of the makefile is another rule. It says that any file ending in .php depends on a file with
the same name with a .webm4 extension, and on all the include files. For example,
The whole point of make programs is to automatically detect when a prerequisite has been changed and to generate
any dependent targets. So when I run
Dynamic processing is what languages like php and asp do. The difference between dynamic and static processing is that while in static processing, the macro expansions etc. are done once, in dynamic processing the server runs through expansions etc. every time a page is requested. So while you can do all the stuff described above using php or asp, and many people, especially non-unix people, do, I think it's a waste of processing power to do it for every request.
What php and the like are really good for is pulling stuff out of a database and putting it on a webpage. They can also take stuff from a form on a webpage and put it into a database. By these powers combined, you can do bulletin boards, blogs, content-management systems, webwide collaboration, and all sorts of good interactive stuff.
If you like security, you might find this more interesting than poring over bugtraq archives.