Ismo Core’s AOP support is getting ready

When finishing up the AOP (Aspect Oriented Programming) support, well actually it’s only support for Interceptors, in Ismo today I came across a slight problem.

I’m using a Dynamic Proxy to proxy the calls to the state class which calls possible interceptors that should be applied. The dynamic proxy uses PHP’s overload extension (I can’t understand why it’s called overload) so that all method calls on the proxy will go through the special __call() method.

This works out fine unless the class the proxy is a proxy for starts calling methods on itself. Because those method calls are done on the real class and not the proxy the interceptors won’t get applied. In Ismo’s case that’s a slight problem as the state classes have a method called execute() which determines the right action method to call, and then calls that method. One big point with implementing support for interceptors is to be able to apply them to the action methods, and now that doesn’t work.

However, I’ll solve that for now by doing a custom execute() method in the proxy, so that the execute() method in the state class won’t be invoked and hence this won’t be aproblem. It’s an ugly solution, but it will have to do for now. In the 0.3.x series of Ismo_Core I’ll correct it the “right way” by refactoring the state classes and action methods. I’ll start by removing the dispatching logic from the state class and create dispatch classes which will handle that part. This will also make it easier to support action classes a la this discussion on the sitepoint forums.

The tricky part is how to map the request url to the right class in a mixed configuration, with some action classes, a couple of states using action classes and finally some states using traditional action methods. It starts to get hard to have some kind of automatic mapping based on the url, but I also want to avoid going the XML configuration way, so I don’t know. I’ll have to ponder this a bit more…

Any bright ideas?