Hugh E. Williams Interview · 2081 words posted 10/05/2004 12:38 PM

Web Database Applications with PHP and MySQL Hugh E. Williams is the Associate Professor in Information Retrieval in the School of Computer Science and IT at RMIT University in Melbourne, Australia. With David Lane, he is co-author of Web Database Applications with PHP and MySQL, 2nd Edition. This interview was conducted via email.

since1968: You wrote the book as an omnibus: with chapters on Entity Relationship modeling and creating PDFs, the book is one of the most useful on my shelf. Who is your target audience? Do HTML designers making the transition to MySQL need to know all this stuff?

Williams: I’m glad you’re finding it useful, that’s great news. Writing books is a solitary experience: you just hope when it’s launched that readers get something from it.

To answer your first question: when I wrote the new edition, the target audience I had in mind was broad. At one extreme, I thought about the reader who knew something about the Web and its standards (such as HTML) and could program a little. At the other extreme, I thought about someone who knew much more: they might have programmed PHP and used MySQL, and might want to know more about OO, PDF production, writing an error handler, more about MySQL, or just see how others thought about issues in in web development. The book would probably be difficult going with no Web or programming experience, and unsatisfying to the experts.

Do HTML designers need to know it all? Probably not, or at least not right away, and I guess that comes back to the broad audience I had in mind when writing it. I tell beginners to read chapters 1 to 3, and 5 and 6. They get you through PHP basics, MySQL basics, and introduce putting the two together. That’s enough to build simple applications and do it reasonably securely. From there, I encourage beginners to read the book as the issues arise: it makes more sense to read about sessions when you’ve banged your head against the wall trying to pass values from one page to the next and on again. A designer might never read about advanced MySQL or OO concepts.

since1968: The ColdFusion community went through a lot of growing pains two years ago when Macromedia added object-oriented features to a procedural language. With the move to PHP 5, it seems like the designers of PHP are saying the same thing: eat your dog food and learn OO. Won’t this scare off HTML designers—the very people originally targeted by PHP? If you really need to work with OO, why not use a scripting environment that’s OO from the ground up, like Ruby?

Williams: I’m with you on this: it’s moving PHP away from its original purpose and towards being an environment where large-scale software engineering seems possible. I’m not convinced that’s a great idea. I’m especially not convinced because there’s very little evidence that OO does anything for software development: I remember investigating the issue a couple of years ago and finding only one published study that compared C with C++. It showed that C++ projects have more bugs, took longer to develop, and were generally less successful. Sure, OO is neat when you finally “get it”, but most people don’t. I certainly don’t find it a comfortable way to program, but then I’ve been a procedural programmer for almost 30 years.

In the book, we’ve strived to walk the line between non-OO and OO. Outside of Chapters 4 [Introduction to OO with PHP 5] and 14 [Advanced Features of OO in PHP 5], you’ll find very little OO, but the OO in those chapters should be enough for readers to understand and use OO concepts. The winestore application very much walks the line between the two: it does OO when it has to (mostly when using PEAR) and otherwise doesn’t.

I actually wrote an OO-only winestore when I was drafting the 2nd edition of the book. It was neat: you could create an HTML form widget, and it knew how to validate itself and deal with errors. The problem came when I wanted to explain it: it’s hard enough writing about large slabs of code, but when you throw OO in the mix, it’s impossible. So, the end result is a winestore that matches how I program: OO when you need it, and procedural otherwise.

It’ll be interesting to see what developers do with PHP 5, but I bet most never use the features that are being trumpeted.

since1968: PEAR DB: to use or not to use? I’ve worked in various scripting environments for about 7 years and I’ve had precisely two projects move from one application server/database configuration to another. Every other project I’ve worked on has stayed with the same database for years at a time—I just can’t see much value in database abstraction. Still, a lot of the popular libraries use PEAR DB. For instance, if I want to use patUser to avoid writing authorization routines from scratch, I’m forced to use PEAR DB. Can you give some advice to beginners who need to weigh the advantages and disadvantages of database abstraction in PHP?

Williams: In my view, you shouldn’t use PEAR DB unless you’re seriously considering migrating your application from one database server to another in the future. Using the native libraries, you get direct access to the tools and features of the database server, and those tools are often richer than the vanilla, generic PEAR DB interfaces. What’s more, direct use of library functions is faster. In my applications, I almost always use MySQL and the libraries directly.

As an aside, even if you use PEAR DB and are thinking about migration, you’ll have other problems when you do. SQL varies between database servers, and so you’ll end up rewriting database code anyway. Just moving our winestore database from the book to Oracle took me half an afternoon, despite using PEAR DB in the application; there were clashes between column names and reserved words, column types that weren’t available, key problems, and all sorts of other changes needed.

since1968: It’s a great time for what I think of as “littleware”: small PHP programs that interact with client-side command line interfaces like curl to produce mini-applications. One of my favorite examples on the Mac is iTunes Watcher, which tracks your iTunes playlists and posts them to your site via PHP and MySQL. Do you have any favorites? Is littleware going to lead to something useful, or is it just some fun noodling around?

Williams: I’ve seen some great little PHP snippets for all sorts of tasks, and I’ll admit to writing many myself. I’ve written a web interface to some footy tipping software recently—I’m not sure how universal footy tipping is, but this allows a group of people to pick winners in our football competition and it produces a ladder each week and there are prizes for the most correct picks in the year. I’ve also fiddled a lot with displaying the weather, simple web cam galleries, page visit counters, and so on. Fun, simple stuff.

It’s noodling around for sure, but that’s not a bad thing. Putting tools on the web makes them accessible and there’s a place for making the web more entertaining. I enjoy that kind of PHP development.

since1968: While I have a large educational client making the transition from IIS to LAMP, I haven’t yet been able to interest a commercial client in PHP and MySQL. Here in the United States, when I say “no vendor lock-in” a business hears “no proper support.” When I say “open source” a business hears “built by geeks, for geeks.” What’s the situation in Australia? Are commercial concerns adopting PHP?

Williams: Being an academic, my overview of what’s happening in the commercial sector is largely formed from the stories I hear from students, ex-students, other staff, and contact with industry. Lately, those stories have been positive for PHP and MySQL. For example, I recently did some training for a development house who’ve taken the decision to do only PHP and MySQL and I hear they’ve landed some great SMEs as clients lately. In the same week, a graphic designer approached me to recommend someone who could build PHP and MySQL backends for her company. I’m sure there’s intense resistance in larger corporations, but when guys like Yahoo! adopt the technology it does help bring it into the mainstream; indeed, “geek” companies like Google and Yahoo! have done a lot to legitimise LAMP (Linux, Apache, Mysql, and PHP).

since1968: Let’s return to PEAR for a moment. I’ve tinkered with PHP for a couple years, but only recently started using it to build medium-sized sites. It’s hard to know when to use various PEAR packages or just write my own routines, especially when so many packages rely on PEAR DB, which you’ve advised against using. What are your thoughts on PEAR generally? Are there any packages you especially like, or any that you would specifically avoid?

Williams: Perhaps I’m contradicting myself, but I wouldn’t necessarily avoid PEAR DB or other database abstraction layers. What I do think is that developers need to to consider carefully why they’d want to use it, rather than blindly make the choice because they’ve heard database abstraction makes for better code or solves problems. It’s useful if you’re planning to migrate database backends, particularly if you’re able to keep your SQL fairly generic. Other than that, stick to the native libraries.

But back to your question. I’m a fan of PEAR, because it saves development time building components that everyone needs. It’s also got that Open Source safety feeling: you know there’s thousands of other developers out there using it, pulling it apart, and pushing it to its limits. That means if there’s a bug, it’s probably been found and fixed.

The downside of PEAR, like much other Open Source software, is that it’s often too new to have been documented properly and the developers don’t necessarily find time to write down what they did. However, that’s no big deal: you usually choose a package because it does what you want, which means you’ve thought about it and are ready to look at the code and understand it.

My favourite PEAR packages include:

There are also a range of other useful packages for meta tasks, such as online payment processing and web services. For specific applications, these can come in very handy.

since1968: Let’s talk about Rich Internet Applications and PHP. Microsoft, one of these years, will roll out Avalon and XAML, which will go a long way toward making web applications feel more like desktop applications. Macromedia has already introduced Flex, a presentation server that, when coupled with a J2EE server for business logic and data access, uses Flash to produce rich interfaces. PHP doesn’t really have anything to compare: you can experiment with “PEAR XML_XUL”:http://pear.php.net/package/XML_XUL; you can work on the desktop with PHP-GTK; or you can hook up PHP to a Flash front end via AMFPHP, but these technologies are either experimental or not central to PHP, which was originally envisioned as a “hypertext processor.” Are there plans to add a rendering engine to the core of PHP? Is is that just extraneous to what PHP is trying to accomplish?

Williams: I’m not sure a rendering engine is where I’d like to see PHP go. PHP’s in danger feature bloat—perhaps it’s already past the point of no return?—and that’d pull it in another, bigger direction. I’d like to see if focus on the core: a hypertext preprocessor that’s fast and scalable under load, and has features that make building applications on the web easier. Indeed, I’ve never really played with PHP-GTK or PHP on the command line: I reckon PHP is great for what it’s designed for, and there are better tools to do other tasks. For example, Perl, awk, and sed do most of the things on the command line I’d want to do.

since1968: Thank you for your time.

Williams: Cheers.

* * *