During my Live Coding sessions at TEK·X* last week, one of the questions that came up repeatedly was:

Events... what are these Event things and why does Flex work like that?

When you initially dive into the world of Flex development**, most PHP'ers will quickly notice something weird. We're out of the world of Request/Response that we know and understand and into an odd world of Events, Listeners, and Publishers/Subscribers where things just don't play well together.

The familiar Request/Response process is similar to going through checkout to the grocery store. The cashier is idle until a new customer appears. The customer makes their requests, the cashier transfers a specified amount from one account to another, and the customer leaves with their results. As more customers appear and the line gets longer, the stores scales horizontally by adding more cashiers. It all scales quickly and easily with minimal effort because grocery store cashiers are a shared-nothing architecture.

Alternatively, the Publisher/Subscriber (or Observer) pattern is similar to waiting at the airport. When you're waiting for a flight, you sit near your gate and wait for an announcement. In the meantime, you might grab a cup of coffee, use the restroom, check email, or make phone calls. The people around you do the same. As announcements are made, some people board their flights or swear at gate agents but regardless until your announcement, you don't care. But once you you hear your announcement, everything changes. You finish whatever you're doing and take action.. along with anyone else listening for the same flight.

This is the core of Event Driven Programming.

Flex** works the same way. As you create elements and functions/methods, they listen for different Events to "fire". Once the Event occurs, all the Listeners attempt their task. The vast majority of these Listeners will not interact with one another but in some cases, Events will fire other Events.

A common task - like Uploading a File - will consist of a number of these Events:

• First, we have to select the file to upload. This could be done via a drag and drop or an explicit file browser option. Either way, the system sits there and waits until a file is selected.
• Next, we need the file to upload. If it begins immediately - like with Gmail - it probably fires from the previous event. Otherwise, it's likely from a user hitting a "Send" or "Done" button.
• Next, we'd like to provide feedback to the user. Since we know the file's size and we can find out how much has been sent, we can calculate a %-complete to update a progress bar.
• Finally, we need to know when the upload is complete. Most likely we have some sort of "WoohooFileUploadComplete" Event we can capture and let the user know. Hopefully, we'll also get back messages from our destination with error messages/status and we can pass them along for the user.

When you stop to consider it, many of the tasks our code performs can be broken down the same way. I believe the primary reason we don't think of it is because the vast majority of our code is entirely on the backend without the ability to even see or capture our events. Obviously, client side technology like Javascript blurs the line, but the concept is the same. If you're venturing into this world, read up on the Publisher/Subscriber Pattern and the Observer Pattern and figure out how to make your code - both on the frontend and back - play nicely together. Jason Sweat's book on PHP Design Patterns is a good place to start.

* The Live Coding in Flex session went amazingly well. I got a number of great questions and a few people were following along typing exactly what I was as I went. Yes, I had some minor technical issues but the audience was incredibly helpful in pointing out my mistakes. Over. And over. And over again.

** The Publisher/Subscriber model actually applies to most if not all desktop development. It's also familiar to the Javascript guys who work with onClick, onLoad, and all those familiar event-related sounding actions.

Disclosure: Through Blue Parabola, we're working with Adobe and Flex in a number of things. Regardless, I choose to explore Flex for the first time long before that.