Sebastian Bergmann

Version 1.2 of the Workflow component that is part of the eZ Components introduces a plugin system that allows developers to hook into the workflow engine at well-defined extension points.

For now, plugin code can be called

• after an execution has been started
• after an execution has been suspended
• after an execution has been resumed
• after an execution has been cancelled
• after an execution has successfully ended
• before a node is activated
• after a node has been activated
• after a node has been executed
• after a service object has been rolled back
• after a new thread has been started
• after a thread has ended
• before a variable is set
• after a variable has been set
• before a variable is unset
• after a variable has been unset

ezcWorkflowExecutionListenerPlugin and ezcWorkflowExecutionVisualizerPlugin are two workflow execution engine plugins that will ship with Workflow 1.2. The former is a refactored version of the execution logging code of Workflow versions 1.0-1.1.

The latter is new and can be used to visually log the execution of a workflow as shown below.

The ezcWorkflowExecutionVisualizerPlugin generates a series of DOT files that can be rendered into single pictures using GraphViz. For the animation above, I crudely joined the single images to an animated GIF.

The before hooks are special as they allow the plugin to change (or even prevent) the current execution step. This will eventually allow for Aspect-Oriented Programming on the workflow level.

The Extended Reflection API enhances PHP 5 by providing access to type information and annotations that are embedded as doc-comments into the sourcecode.

Processable additions to the source code enable a wide range of new applications in general, and Web Services and Aspect-Oriented Programming in particular.

Over a year ago I started to work on a similar project. Due to time limitations this effort never reached a state I was comfortable with for a first release. Today I removed the initial sources from PEAR's CVS repository.

A paper ("GAP: Generic Aspects for PHP") written by Günter Kniesel and myself has been accepted to the 3rd European Workshop on Aspects in Software that will be held in Enschede, The Netherlands on August 31 and September 1 2006.

Here is the abstract:

In this paper, we explore how aspect-oriented programming can be implemented for the PHP programming language. We start with an overview of existing implementations, identifying their strengths and weaknesses. We then introduce GAP, our implementation of aspect-oriented programming for PHP that uses dynamic weaving, supports aspect genericity, and provides a framework to implement custom pointcut languages on top of it.

The sum of these features has previously been supported only in experimental research prototypes that have had little impact on commercial software development. In contrast, PHP has a large user community. In the last decade, it has developed from a niche language for adding dynamic functionality to small websites to a powerful tool making strong inroads into large-scale, business-critical Web systems. We expect that GAP will significantly ease development of such systems while promoting a seamless integration of many advanced concepts of aspect-oriented systems: aspect genericity, dynamic weaving, a state-sensitive pointcut language, and extensibility.

A predecessor of GAP was presented at the AOSD.2006 under the name AspectPHP. We have chosen to rename our approach to GAP in order to avoid confusion with the aspectPHP project and to emphasize the support for aspect genericity.

As I wrote earlier, I am not satisfied with the Current State of AOP for PHP and started to work on AspectPHP a while ago. Today I am going to share my ideas on the subject.

What sets AspectPHP apart from other implementations of Aspect-Oriented Programming is its simplicity: aspects are plain PHP classes that declare pointcuts using annotations.

The $joinPoint variable, which is passed to the method that is used as an advice, contains all information relevant to the join point that triggered the execution of the advice.

The example belows shows how to declare an aspect that logs all method calls:

<?php
/**
 * An aspect that logs all method calls.
 *
 * Declare a new pointcut named callPointCut using the @pointcut
 * annotation that captures join points on a method regardless of
 * modifier, class, method, or number of parameters.
 * @pointcut callPointCut : call(* *->*(..));
 *
 * Bind the after() method of this aspect as an after-advice to the
 * previously declared pointcut.
 * @after callPointCut : LoggingAspect->after();
 */
class LoggingAspect
{
    public function after($joinPoint)
    {
        printf(
          "%s->%s() called %s->%s()\n",
 
          $joinPoint->getSource()->getDeclaringClass()->getName(),
          $joinPoint->getSource()->getName(),
          $joinPoint->getTarget()->getDeclaringClass()->getName(),
          $joinPoint->getTarget()->getName()
        );
    }
}
?>

Unfortunately, I am too busy with other projects (preparing for my final two exams and working on PHPUnit 3) and therefore cannot offer any downloadable code at this point.

I hope to make an initial code release within the next two months.

I know about four existing approaches to faciliate Aspect-Oriented Programming with the PHP Programming Language:

• PHPAspect uses a compiler, written in the PHP programming language, that performs static weaving using source code transformations. A downside of this approach is that advantages that stem from PHP's interpreted nature are lost.
  
  
• Aspect-Oriented PHP uses a preprocessor for the PHP programming language written in Java that is responsible for the weaving of aspect- and base-code. Due to its Java implementation this approach does not integrate seamlessly with the PHP platform.
  
  
• aspectPHP is a reimplementation of Aspect-Oriented PHP in C, available as a patch against (not as an extension to) PHP 4.3.10.
  
  
• The AOP Library for PHP requires manual changes to the base-code and thus does not provide obliviousness.

Since I was not satisfied with either of these approaches, I started to work on my own extension for Aspect-Oriented Programming to the PHP Programming Language, AspectPHP, a while ago.