Tag Archive for 'aop'

Upgrading to Wordpress 2.3.2

How unsexy are Wordpress security updates? I have the horrible habit of doing everything else first before attempting one (which, of course, is absolutely the worst thing you can do, as the recent spam hack on the SWX blog demonstrated so well). I used to dread doing the updates mainly because I just knew something would break. At least that's how I used to feel.

When I last upgraded Wordpress, a little over a week ago to version 2.3.1, I made a slightly delayed New Year's resolution that I wouldn't hack the blog. Instead, I decided to do everything using plugins and widgets (which are plugins that display on your sidebar). And -- wonder of wonders -- I actually stuck to it! That being the case, upgrading is no longer a nightmare.

In fact, when you have an unhacked Wordpress installation, all you have to do to upgrade to 2.3.2 is:

  1. Download 2.3.2.
  2. Delete the wp-content folder and the sample wp-config file from the distribution.
  3. Test it locally on your development machine (skip this step at your own peril; the last thing you want is all your readers discovering your "Doh!" moment mistake at the same time as you do!)
  4. Upload the new files to your server.

That's it. All in all, it took me under ten minutes to do. As there were no database changes between the two versions, I didn't even have to run the upgrade script (which I realized after running it on my local installation and seeing the resulting message.)

The moral of the story is that if you don't hack your blog but use plugins for everything, upgrading no longer needs to be a nightmare. Using a plugin-based architecture (which in Wordpress shares similarities with aspects and the Template pattern in object/aspect-oriented programming) gives you flexibility in customizing something without altering the original, thereby making updates to the original possible without breaking your customization.

The same moral holds true for development when you're using third-party libraries. Instead of hacking them, see if you can't extend their capabilities either via inheritance, or, even better (because it's more flexible), through composition (say via the Decorator pattern or by using interceptors). That way, unless the public API of the library changes, you won't be afraid to update the library to its latest version. (And, if you're designing an API, see if you can't include some hooks or filters in there to make it easier for people to extend it without too much trouble.)

To cut a long story short, the blog's now running Wordpress 2.3.2 and all is well. It's also a real pleasure to actually find myself looking forward to the next Wordpress update rather than dreading it! :)

AOP vs. The Interceptor vs. The Template

No, it's not some crazy tag-team wrestling line-up. I was side-tracked in one of my Googling expeditions and came across a blog entry by Ted Neward titled Setting the Story Straight: AOP != Interception. In it, Ted provides an interesting comparison of the Interception pattern and Aspect-Oriented Programming.

Interception and AOP also have parallels with the Decorator pattern, filters and the Template method (in which you set up your Template methods so that they call hook operations that can be overriden by subclasses.) These concepts and patterns can be useful in Flash and ActionScript development too. For example, the Template pattern is used for the base classes in ARP and I had used Interception in the past to decorate the functionality of a method (I'll be damned if I can remember what exactly it was for.)

After reading Ted's post, I thought I'd whip up a reusable way to easily decorate methods and came up with the Aspect class presented below (it should perhaps rather be called Interceptor or MethodDecorator.) The Aspect class allows you to modify the behavior of a method by specifying that another method (which I've called an Advice, following the term used in AOP) be executed before (default) or after the method.

This is a naive first implementation and I have neither given it too much thought nor tested it out exhaustively so treat it as experimental code and feel free to send me suggestions and improvements. Here it is for you to play with...

// Class: Aspect
// Allows you to weave in advice (other methods) before and after the original method.
// Copyright (c) 2005 Aral Balkan
// Released under the MIT License.
class Aspect
{
    var originalObject:Object;
    var originalMethodRef:Function; // Reference to the original method
    var originalMethodName:String;
    var copyOfOriginalMethod:Function; // Local copy of original function
    var advice:Function; // Code to weave in
    var after:Boolean = false;
 
    function Aspect (obj:Object, methodName:String, advice:Function, after:Boolean)
    {
        originalObject = obj;
        originalMethodName = methodName;
        originalMethodRef = obj[methodName];
 
        // Save a local copy of the original method
        copyOfOriginalMethod = obj[methodName];
 
        // Save the advice method
        this.advice = advice;
 
        // Should the advice be executed after the original
        // method? (Defaults to false so the advice is executed
        // prior to the original method.
        if (after != undefined) this.after = after;
 
        // Overwrite the original method with a proxy function
        // to relay calls to the Aspect object
        obj[methodName] = function()
        {
            // Call the execute method on the Aspect
            arguments.callee.aspectRef.execute.apply (arguments.callee.aspectRef, arguments);
        }
 
        // Add a reference to this instance on the
        // target method's activation object so it has a
        // way to refer to us.
        obj[methodName].aspectRef = this;
    }
 
    // Executes the advice and the original method.
    function execute()
    {
        // Should the advice be applied prior to the original method call?
        if (!after) advice.apply (originalObject, arguments);
 
        // Original method call
        copyOfOriginalMethod.apply (originalObject, arguments);
 
        // Should the advice be applied after the original method call?
        if ( after ) advice.apply(originalObject, arguments);
    }
}

To test it out, enter the following script into the first frame of an empty FLA placed in the same folder as the Aspect class:

// Create the original method
originalMethod = function() { trace ("Original method") };
 
// Create two new advices
firstAdvice = function() { trace ("Before original method") };
secondAdvice = function() { trace ("After original method") };
 
// Create the two aspects
firstAspect = new Aspect(this, "originalMethod", firstAdvice );
secondAspect = new Aspect(this, "originalMethod", secondAdvice, true);
 
// Call the original method
originalMethod();

The output should be:

Before original method
Original method
After original method

I'm sure you'll find some cool uses for this! :)






Bad Behavior has blocked 0 access attempts in the last 7 days.