Web Programming Theory

Warning, this is a nerdy post. Moreso than normal even. As I was visiting a site this morning that was having problems and spitting out random PHP error messages, I was reminded that I wanted to write up something about web programming. No I’m not going to name the site, but they should know better. And this is not a post bashing PHP, because like many things PHP can be used for good as well as evil. During one of our web redesigns at ONElist , a couple of our very smart engineers developed a new templating system, called CS/HDF, named after the two types of files that are involved. Later, Dave Jeske and Brandon Long wrote an open-source version of CS/HDF, called Clearsilver. It’s an excellent implementation, and it’s what we use for Bloglines. I won’t go into explaining how Clearsilver works; the web site’s got some pretty good docs in that regard. But I want to mention the design philosophy of the system. Basically, Clearsilver forces the developer to seperate application logic from the presentation layer. What does that mean? Before Clearsilver is given the chance to build a web page, all variables required for building that web page are populated. Once Clearsilver takes over, no additional data is input, no database calls are made, nothing. By the time that Clearsilver is processing the page, the application knows whether it was able to fetch all the data and whether there were any errors in processing it. How is this good? A couple of reasons. First, since the display layer is already extracted, it’s very easy to redesign the look of or internationalize the web site. No need to worry about messing up any application logic while editing templates. Also, there will never be any mysterious error messages showing up in the middle of the page whenever something fails. By the time the template is processed you know for certain whether you have all the information you need to display the page. That makes it easier to craft error dialogs. Ever been surfing a web site, and you see half the page come up, and then wait 30 seconds for the rest of the page to complete? That happens when the data required for the web page is fetched after the page has started to display. That makes it much more difficult to craft good error dialogs. If I want the look of the page to completely change if there’s an error, I can’t do that if I find out about the error after half the page has already been sent to the client web browser. Again, I’m not bashing PHP. I believe you can program in this style using PHP as well, but it’s not enforced. The language is not important (although Clearsilver is very good and deserves more recognition). The seperation of application logic from display is what matters.