In the previous part of this series we learned what Aspect Oriented Programming (AOP) is and the meaning of important AOP terminology. In this part I'll explain why we need AOP using practical examples and how to add AOP behavior to your PHP application using the CodeIgniter framework.

They start with a look at a few pieces of functionality that could cut across multiple parts of the application like logging or authentication/authorization. They show how to use the "hooks" feature of CodeIgniter to implement the AOP proxy class generation, executing pre- and post-controller.

The current list includes:

• Test Strategy: Scripted Test
• Design for Testability: Dependency Injection
• Fixture Setup: Delegated Setup
• Fixture Teardown: Automated Teardown
• Test Double: Mock Object

There's lots more where these came from, all divided into sections like "Fixture Setup", "Test Double" and "Database Isolation" patterns. You can find the full list so far here.

PHP 5.3 packaged the power of functional programming by adding support for lambda functions and closures. You will be familiar with them in javascript. In this article we will have a look into these features and its usages.

He starts with explanations of what they are with simple code examples showing their use - a lambda assigned to a variable and closures with the "use" keyword. He shows how they can be used in application prototyping, making handy callback functions and includes a practical example of finding the factorial of a number using a lambda.

If you're like me, you might be wondering what the practical uses for these new features are before you can rightly justify diving in and using them in new or existing projects. I experimented a lot with closures and possible uses over the past few weeks, and came up with some compelling reasons to start using them.

He's come up with five different examples of how you can use this handy feature:

• Templating
• Dynamic Code Extension
• Delayed Execution
• Caching
• Convenience (as in their role in one-off functions for callbacks)

Each of the tips comes with a bit of code (except delayed execution, that's a bit more involved) to help explain the point a bit more.

Observer is a pattern where an object called the subject maintains a list of dependents (observers) and notifies them of any state changes. I implemented this recently to log changes to an Account object, and to notify the account holder if their account had expire - here's the basics of the code, hopefully it'll help someone else figure out how the pattern works

The basis of the Observer pattern is that you attach these "observer" objects to a main object. These watch the object and see if something changes (like a property value) and react accordingly. For their example, they create a setup that extends the main Observer class to have some or the detection functionality built-in.

No matter how advanced the techniques that we use, there is always something that we could be doing better. [...] Which one is right? The real problem is that the answer to that question is, "yes." That's because it lacks a specific context in which it can be inserted.

He suggests that, in our quest to figure out what the perfect case for any situation, we stop focusing on the practicality of writing applications to accomplish goals. Sometimes it's not about getting the right theory behind the code - sometimes it's just doing it.

Did you know that Zend Server not only has it's own PHP accelerator built in (like APC). But that it also has similar functionality allowing for caching of data in shared memory? Shahar Evron, Project Manager of Zend Server, has written a white paper describing just how exactly to use this to good effect.

Caching is one of the simplest ways to increase the speed of your application and Zend Server makes it simple with its included Optimizer+, Zend Page Cache and Data Cache API tools. For more information, you can download the whitepaper here [pdf].

Most web applications use forms. Forms often represent some model, such as a news post. If the model is simple, writing the form in HTML is not too bad, or we might be able to use a scaffolding feature in our framework. [...] Here's a good use for reflection! Since in models we often have a naming scheme for the data the users would be able to input, we can utilize this knowledge with reflection to generate a list of possible fields in the model, and then generate the form with less typing required from us.

His example looks into the model class and pulls out the "get" functions and, after pulling out the name, adds it to a fields array. This array is then passed out to the display part of the script and looped over to create a text field for each. He expands it a bit to also include checking for "@return" values in docblock comments for the type of form field that should be displayed.

Questions include:

• Should I buy it? (who is it targeted towards)
• Will it get old too soon?
• Should I wait to the new edition of the book?
• Are the contents of the book full color or b&w?
• Should I buy the book or print The definitive guide to symfony 1.2?

The book can be ordered in three versions - Propel (English), Doctrine (English) and Propel (Spanish).

Two years after the publishing of "The Definitive Guide to symfony" book, I am happy to announce that the Jobeet tutorial is now available as a printed book: "Practical symfony". During the last two weeks, I have updated and enhanced the Jobeet tutorial based on the feedback from the community. I have also updated the screenshots to reflect the new Jobeet design. The "Practical symfony" book is the printed version of this tutorial and as such covers the symfony 1.2 version.

The Jobeet tutorial was their 2008 "advent" piece that created a job posting website from scratch with each day focusing on a different aspect of the application. There are two versions of the book (Propel and Doctrine) but for now, only the Propel version can be purchased over on lulu.com.