In the previous parts of the series we learned about AOP concepts and the need for using AOP in large scale projects and I introduced CodeIgniter's hooks as a convenient mechanism for creating AOP functionality from scratch. In this part I'll show you how to use both XML and comment-based techniques to create custom AOP functionality when a dedicated AOP framework is not available.

They start with the XML configuration that defines a few aspects and pointcuts for the application. This is then read in via the "applyBeforeAspects" and the aspects that should be executed first are extracted, loaded and run. Following this, they take the other approach - based on docblock comments - and pull in the comments (the @before and @after tags) and load/execute the aspects that way instead.

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.

Have you ever heard of Aspect Oriented Programming (AOP) before? It's a widely used concept in developing enterprise level systems, although it hasn't seen much use in PHP. I'm going to use this article as an opportunity to introduce PHP developers to AOP. This tutorial will be delivered to you as a 3-part series. In this part I'll explain the concepts of AOP. In part 2 I'll show you the practical uses of AOP and creating a AOP rules structure. Finally, I'll show you how to integrate AOP functionality using CodeIgniter in part 3.

Since this is just part one, they mainly focus on some of the key points of AOP like aspects, advice, jointpoint and pointcuts. For each, there's brief descriptions for the types and, for some, code samples showing the idea in action.

This article will show how we can develop software in php with a nifty design and architecture, and very much like other languages like java, using an ORM and an AOP, DI, Events container. I will assume you've read (or at least took a quick look) at this article that explains the tree layout used throughout the code, and that you have some basic knowledge of Doctrine2 and used it before on your own.

He starts with the result - an easy to use, self-contained (and decoupled) system for accessing the Doctrine2 instance. It's event-driven and uses Aspect-oriented programming to mange interactions between components (or as he calls them "beans"). Code is included for the entire process for a logger, the User entity, entity manager, user repository and transactional aspect. You can find the complete source for his example on his github account.

Last month, during PHP Advent, gwoo wrote an interesting post on Aspect-Oriented Design, or Aspect Oriented Programming (AOP) as it is more commonly known. The article got me to thinking, and revisiting what I know about AOP, Intercepting Filters, and Signal Slots -- in particular, what use cases I see for them, what the state of current PHP offerings are, and where the future may lie.

He gives a base class to help make things a bit clearer for the rest of the post - a simple Foo instance that uses a Listener interface to "doSomething". Matthew also talks about intercepting filters (extracting things like logging/debugging out of the code and put on its own) and signal slots. For both, he gives examples of how Lithium handles them and some of his opinions on the methods. He points out a few concerns that he has for the current state of AOP in PHP (frameworks) and suggests that, if you haven't looked at these ideas, you do so sooner rather than later.

As far as I can tell, Lithium is trying it's hardest to be fast, lightweight, and use all the features that PHP 5.3 has to offer. [...] I want to talk about something that I feel is a very underrated part of Lithium, the ability to define filters. This is a concept that you find in Aspect-oriented programming, and one that I imagine most programmers have never considered. Here's why I think it's a big deal.

The filters in Lithium allow you to use code from other classes without having to actually extend them. As Nate Abele says in one of the comments on the post:

While not having to extend classes or dig inside core functionality is certainly pretty central, the way I've been explaining it is that it's important because classes no longer need to know anything about each other in order to be integrated.

You can find out more about the Lithium project (and RAD-Dev) on the project's wiki.

The first news concerns the windows developers, the windows build of PHP_Parse_Tree is finally available (click here to download)! [...] The second news is that my proposal "phpAspect eclipse plugin" for the Google Summer of Code 2007 under the mentoring of Gilles Vanwormhoudt has been accepted!

Be sure to keep an eye on the project's website and their Summer of Code page to keep up with the latest.

I will be performing a talk about phpAspect at Solution Linux 2007, the 31th january 2007 and a lightning talk at FOSDEM next month. I'm looking forward to collect your feedbacks, questions and suggestions about phpAspect!

The Solution Linux 2007 conference is happening in Paris from the 30th of January to the 1st of February. FOSDEM will be in Brussels, Belgium and is happening the 24th and 25th of February.