January 7th, 2009


Most of P'unk Avenue's projects are built with Symfony, a web application framework that greatly accelerates the process of developing web sites like the GPTMC Pressroom, DukeLIST and (to be a bit more frivolous) 5seven5.

You'll note that these sites don't have that much in common at first glance. The first is a central repository of press releases, photos and video of local interest. The second is a Craigslist-like site for the Duke University community. And the third is a social network for haiku poets.

Under the hood, though: they have something crucial in common: they are highly dynamic sites. The content is ever-changing. Static HTML pages aren't much use in this situation.

The old-fashioned solution, sprinkling PHP code into HTML pages a little at a time to make them more dynamic, is still a great way for beginners to learn about PHP. But it's not a good way to go about implementing a large web site with an extensive feature set... unless you like repeating yourself.

Which leads us to a common mantra in the Symfony development community, among others: Don't Repeat Yourself (DRY).

Avoiding the need for repetitive coding is a big part of the Symfony philosophy. Symfony's helper functions handle the tedious tasks of inserting common HTML comments like image tags and form elements, and Symfony 1.2's form classes abstract the problem away even further, allowing you to define forms with a minimum of pain and suffering. The Propel and Doctrine ORMs (Object Relational Mappings) provide ready-to-rock interfaces between SQL databases and object-oriented programming. And Symfony's modules, actions, routing rules, components and templates put an end to the endless cascades of "if... then... else" statements that decide how to handle the user's actions in so many PHP scripts. Indeed, they bring back some of the traditional elegance of designing a static site, by allowing URLs to define the structure of the site in a meaningful way with folder-like structures.

Inspired by the high degree of code reuse in Symfony... and by a sense of frustration we experience each time we're forced to do the same darn thing... we do our best to avoid coding anything twice around here.

But Don't Repeat Yourself (DRY) is only part of the solution. Don't Repeat Anybody Else, Either (DRAEE). Symfony's plugin architecture simplifies the process of reusing code written by others. And that's where the Symfony community shines, with 392 plugins in the official repository alone. Existing Symfony plugins provide ready-to-go solutions to add blogging, photo management, tagging, and page content management.

One of the more popular recent plugins is sfLucenePlugin, which adds a high-quality search engine to Symfony applications with very little work. sfLucenePlugin itself is a wrapper around Zend Lucene, an open source text search engine, which is a PHP port of Apache Lucene, which implements the same algorithms in Java. Reinventing this stuff is for dummies.

We're not quite at the end of the story, though. There's one more chapter: FDLFRTE (Friends Don't Let Friends Repeat Themselves Either). Do you have code you reuse in your own projects? Good for you. Is it possible that code would benefit others? Sure, but that doesn't justify the time it takes to release it... or does it?

Consider these selfish motivations for releasing your frequently reused code as open source for others to benefit from:

1. Other people will find your bugs. 2. Other people may even fix your bugs. 3. Shame will motivate you to clean up the code considerably before you release it. 4. With luck, you'll even be moved to test your code before you let others play with it. 5. You'll think of ways the code could be more general and more useful to more people, and add features that benefit your own projects as well as a result.

In a nutshell, releasing your code as open source pushes you to increase its quality and brings other people into the quality control process, as well as the development process.

This is why we've released quite a few Symfony plugins this year, as you'll see.

Lots of sites require users to log in. Symfony's sfGuardPlugin is great for managing user accounts. But if you want to allow users to create accounts, you're stuck reinventing the wheel... or you were, until we released sfApplyPlugin.

pkAdminQuickCreatePlugin makes it easy to "just add another DJ to the system" while you're adding a club night to the system, then return without losing your work... if, let's say, you're building a site like Salsadelphia. We first went down this road when adding similar features to the GPTMC Pressroom. When I realized I was coding it again, I knew it was time for a plugin to save ourselves and others the trouble.

Symfony's admin generator (a DRY masterpiece if ever there was one) is great for managing databases of information in a user-friendly way with a minimum of coding on your part. The resulting sites have good sorting features, but not when the column you're sorting on is actually a reference to another table. sfAdminSortByForeignNamePlugin fills that gap.

This is just the tip of the iceberg. We've been very busy releasing Symfony plugins and contributing to existing parts of Symfony, most notably adding features to filter users by category (admins, editors, peons...) to sfGuardUser.

Contributing to open source projects is much easier than you probably think. And the rewards for your own work are considerable. it's not hard to see the benefit to the bottom line when projects are assembled from better-tested, better-designed components in less time and with less aggravation.

Alert readers might note that two of the sites I've linked to here, 5seven5 and Salsadelphia, are projects of my own not built at work. So my use of the pronoun "we" throughout this post might seem a bit strange. But that just points out another benefit of open source: I don't have to be sneaky about reusing code written at work on my own projects, or indeed vice versa. If I want to use it on my own projects, I let the P'unk gang know I'm intending to release it as a Symfony plug-in, get their buy-in, and do that. Now I'm allowed to use that code anywhere else I see fit as well. And if I want to bring something I've built at home (such as sfApplyPlugin) into the office, the same applies in reverse: I open source it as a Symfony plug-in so that everyone, including my coworkers, can benefit.

So for the purposes of this article, "we" refers to "Tom and P'unk Avenue." But once it's been released under the MIT License, it's out there for anyone to benefit and profit from.

I'll have more to say about Symfony at Refresh Philly this coming Monday night. Check out the Refresh Philly site and be sure to RSVP to attend!
Check out another article
January 5th, 2009
Holiday Punctuation