As we roll along towards Arbor Day, April 28, 2006, when all will be revealed, let’s talk about another aspect of PHP application design that Willowgarden will impact dramatically.

Every piece of software can be described and articulated via a set of core concepts. Often, these ways of building software mirror concepts we understand in real-life. For instance, software in the past was usually built using a semi-linear series of operations (procedures). We humans perform a series of operations to get things done as well. But that way of building software has gradually given way to a new object-oriented paradigm. We interact with objects in real-life, and we can perform tasks using objects and objects themselves can perform tasks, so those concepts are also easy to understand in the software world.

A more recent set of core concepts has grown around the need to modify software after its basic building blocks have been developed. Object-oriented programming starts to lose its appeal when it comes to making basic changes over a broad sub-section of an application. The latest buzzword in programming that attempts to solve this is aspect-oriented programming, or AOP. AOP provides a way to intercept vital code points (typically the start or end of object methods) in an already-built application and run new code to modify the application at run-time. I won’t go into all the technical jargon, but let’s just say it’s gotten pretty popular in the Java community.

AOP is very exciting, but it’s also relies on extending the core language to work its magic, and therefore it hasn’t really taken off in the PHP community. However, AOP isn’t the only paradigm available to solve this sort of problem. We can look at different patterns already widely used in the software world and apply them in these types of situations. I’m talking about event-driven programming and the Observer pattern.

Event-driven programming is also easy to visualize in human terms. We humans operate on events all the time. When your alarm clock wakes you up in the morning, there’s an event. When someone knocks on your door, there’s an event. Paring events with the Observer pattern is easy and incredibly useful. To put it in computer terms, the alarm clock is the subject, the “beep beep beep” is the notification, you are the observer, and your “callback” performs the task of waking up and getting out of bed.

Now let’s think about the typical PHP application. If we break it down into events, there are many obvious places where events can occur. There’s the event of loading configuration files and connecting to databases. There’s the event of processing an incoming request URL. There’s the event of determining what code (i. e., which object) should be asked to handle a request. There’s the event of loading data from a database. There’s the event of sending output data (HTML, etc.) to a browser.

Obviously, all those events are simply tasks that can be built using standard OOP or even procedural programming. Nothing wrong with that. But what happens down the road when you decide you need to perform some additional tasks at any of those various event points? What happens when you need to perform the same task no matter which object is handling the event? Even more importantly, what happens when someone else wants to perform additional tasks after receiving your complete, packaged app? What happens when YOU want to extend, modify, enhance, and alter the behavior of a complete, packaged app you just downloaded? Do you really want to go mess around with core source code you didn’t write? Do you really want to make modifications that create huge hassles down the road when you want to upgrade that app to the latest release?

If you’ve been using PHP for any length of time at all, you know exactly what I’m talking about. This is the Achilles’ heel of open source: if you change that source, you’re responsible for figuring out how to upgrade later. It’s a real pain sometimes. And it’s also time-consuming to paw through a bunch of code you didn’t write. Wouldn’t it be great if you could just write an observer that would notified when an event in the app occurred and could perform some tasks in a simple callback function?

Willowgarden aims to solve these problems by providing a standardized, accessible, and friendly event system that exposes hooks into every stage of an application’s lifecycle, allowing you to add new functionality to existing applications. It provides many of the same benefits as aspect-oriented programming, but without the complexity and the problematic language extension issues.

This entry was posted on Tuesday, April 25th, 2006 at 9:26 am and is filed under Design Philosophy, Willowgarden. You can follow any responses to this entry through the RSS 2.0 feed. Both comments and pings are currently closed.