Here are a list of the most useful methods in this CFC
getMethod() : Get the name of the method (join point) that we are proxying and is being executed
getMethodMetadata() : Get the metadata structure of the current executing method. A great way to check for annotations on the method (join point)
getArgs() : Get the argument collection of the method call
setArgs() : Override the argument collection of the method call
getTarget() : Get the object reference to the target object
getTargetName() : Get the name of the target object
getTargetMapping() : Get the object mapping of the proxied object. Great for getting metadata information about the object, extra attributes, etc.
proceed() : This is where the magic happens, this method tells WireBox AOP to continue to execute the target method. If you do not call this in your aspect, then the proxyied method will NOT be executed.
The last method is the most important one as it tells WireBox AOP to continue executing either more aspects, the proxyed method or nothing at all.
Here is my MethodLogger aspect that I will create:
You can see that I do some DI via annotations:
A normal constructor with one optional argument for logging results:
And our invokeMethod implementation:
As you can see, the before advice part is what happens before the execution of the real method (or more aspects) occurrs. So everything before the call to arguments.invocation.proceed():
Then we execute the real method or more aspects (we do not do anything around the method call):
Finally, we do the after advice part which happens after the method or other aspects fire and results are returned:
That's it. I have succesfully created an aspect. What's next!
Now that we have activated the AOP engine, let's build a simple method logger aspect that will intercept before our method is called and after our method is called. So if you remember your AOP dictionary terms, we will create an aspect that does a before and after advice on the method. Phew! To do this we must implement a CFC that WireBox AOP gives you as a template: wirebox.system.aop.MethodInterceptor. This CFC interface looks like this:
This means, that we must create a CFC that implements the invokeMethod method with our own custom code. It also receives 1 argument called invocation that maps to a CFC called wirebox.system.aop.MethodInvocation that you can learn from our cool API.
Our approach to AOP is simplicity, therefore this invokeMethod implements the most powerful advice called around advice, so you will always do an around advice, but it will be up to your custom code to decide what it does before (beforeAdvice), around (aroundAdvice) and after (afterAdvice) the method call.
The other advantage of WireBox AOP aspects is that once they are registered with WireBox they act just like normal DI objects in WireBox, therefore you can apply any type of dependency injection to them.