design and data
Saturday, April 29 2006
I was up to my gills all day in a web project, trying to integrate a phpbb message board system into a client's site. The code used in phpbb is proving to be very difficult to use, since it does a number of things that I learned long ago not to do, while doing other things that are great in principle but which often cause trouble when put into practice. The main problem with most of the code is that it tends to be of a spaghetti nature, with little effort put into breaking it up into functions. Even when functions are used, they make use of long lists of global variables and it is impossible to tell whether the functions' purported actions are more important than their side effects. Another problem with the code involves reliance on session objects, which add a level of completely unnecessary complexity to something that can easily be handled with a simple cookie pointing to a trove of data in a database.
But the most maddening thing about the code is the thing that is good in principle but which is usually a disaster in practice: the separation of program logic from formatting. I'm actually a firm believer in this idea, where practical or logical. I think, for example, that if you have a function for looking up a username, there's no sense in it returning formatting HTML, unless (of course) the function is to return a formatted username. I also think cascading style sheets (CSS) are a great way to keep the imprecise and ever-changing Tropical Hippie Republic of Design away from the more logical and straight-forward Germanic Autocracy of Data. But for years there have also been attempts to completely segregate data and HTML from each other on the web server as well, usually through the use of templates that are stuffed with HTML on the fly. Such systems are praised because they allow designers to design pretty templates while letting coders worry about the databases and application logic. In practice, though, these templating languages are themselves languages which must be learned, and frustrating ones at that due to their lack of backend access. Furthermore, such templates tend to break more easily and are harder to debug than a simple PHP page containing both SQL an HTML. Finally, the separation imposed by the use of templates has a very serious consequence for small development teams: a developer working to implement some feature at all levels find himself shuffling from front end to back end in numerous far-flung corners of the website's filesystem to make even small changes. It's much more conveninent to have all the code for a particular front-end component in one place, where fundamental (non-CSS) design changes can be made at the same time as alterations to the nature of the SQL queries. I personally like to keep the code for even my most complex web systems to just a few files, all of it organized into functions that don't refer to global variables, have no side effects, and return a single value. That value can be anything from a numeric userid to a whole page of HTML, which, if it's complete, can then be echoed.
The lack of functional modularity and the reliance on yet another template system makes phbb close to impossible to work with. An example of what I mean is its built-in polling system. I couldn't tell from the database how its polls were stored, and I couldn't tell from the spaghetti of PHP how to generate just a single poll question with options for answers (let alone how to actually handle an attempt by a user to vote). In the end is was easiest to just build my own system from scratch using a tried-and-true three-table recipe from my old Vodkatea.com experiments. After blowing my entire Saturday night fighting with phpbb, I wished I'd built a whole message board system from scratch. My satisfaction level would have been much higher. Instead, it seemed as if I'd spent the equivalent amount of time putting, so to speak, lipstick on a pig (only to find I'd put it on the wrong end).
For linking purposes this article's URL is:feedback
previous | next