Ed Zynda has a recent post to his site looking at the use of the Interceptor design pattern with the aspect oriented methodology in PHP. He doesn't get into the basic concepts of AOP, so you might want to find out a bit more in other places. It's not a necessity, though, as his code examples are easy enough to follow along.

There are many ways to modify the behavior of existing code with actually changing the core logic. Some patterns you might be familiar with are the decorator pattern or the observer pattern. Both allow you to take another object and modify the behavior by wrapping your modifications around the original code. One pattern you might not be familiar with though, is the interceptor pattern.

He first helps you install the AOP-PHP extension to provide some of the necessary PHP functions. From there he talks about using some of the functions that intercept function calls and perform an action. He shows examples of it using:

• aop_add_before
• aop_add_after
• aop_add_around

He also shows how to modify arguments during execution and changing return variables when the execution of the function is completed.

Michael Girouard has a post on his blog about something that's becoming more and more wide-spread in the PHP community (thankfully) - filtering input from users and escaping the output to ensure the safety of your application.

The idea itself is simple. When data comes into your application, it must be filtered prior to it actually being used for any reason. This means all data. Form values, URL values, and yes, even the values in the forever useful $_SERVER superglobal. [...] Before leaving your application, data should be properly escaped with the specific output medium in mind.

Previously he showed how, using an interceptor method in PHP5, you could build "collections of data". He uses the same sort of method here, appling custom filters to the data based on the output call. Code is included for both the filtering interface and two example filters - one for SQL and the other for HTML.

You can also grab the code if you just want to play with that.

Michael Girouard has a post on his blog about something that's becoming more and more wide-spread in the PHP community (thankfully) - filtering input from users and escaping the output to ensure the safety of your application.

The idea itself is simple. When data comes into your application, it must be filtered prior to it actually being used for any reason. This means all data. Form values, URL values, and yes, even the values in the forever useful $_SERVER superglobal. [...] Before leaving your application, data should be properly escaped with the specific output medium in mind.

Previously he showed how, using an interceptor method in PHP5, you could build "collections of data". He uses the same sort of method here, appling custom filters to the data based on the output call. Code is included for both the filtering interface and two example filters - one for SQL and the other for HTML.

You can also grab the code if you just want to play with that.

In response to this previous post from Jeff Moore, Tobias Schlitt shares some of his own comments on the subject - mainly that he wholeheartedly agrees.

The usage of interceptors (__get()/__set()/__isset()/__call()) makes your API a lot more readable and comfortable, while maintaining the purpose behind getters and setters: Checking the correctness of values assigned to a property and wrapping around retrieval mechanisms for a property. I personally call the way of maintaining value-correctness for properties through interceptors virtual properties, which fits quite nice I think.

Tobias gives an example of what he means by these "virtual properties" with an illustration from something widely used on the eZ Components libraries - comparing one method of setting text to an object to another (just setting versus the wrappers).

In response to this previous post from Jeff Moore, Tobias Schlitt shares some of his own comments on the subject - mainly that he wholeheartedly agrees.

The usage of interceptors (__get()/__set()/__isset()/__call()) makes your API a lot more readable and comfortable, while maintaining the purpose behind getters and setters: Checking the correctness of values assigned to a property and wrapping around retrieval mechanisms for a property. I personally call the way of maintaining value-correctness for properties through interceptors virtual properties, which fits quite nice I think.

Tobias gives an example of what he means by these "virtual properties" with an illustration from something widely used on the eZ Components libraries - comparing one method of setting text to an object to another (just setting versus the wrappers).