Mootools AOP and how to use AOP for Profiling Mootools Classes

In my last post about Mootools private pattern mutator, I've show how to use keeto's patternmutator to inject a private object into mootools methods.
Using this private object it is then possible to add private properties and methods which are accessible only to methods decorated with 'private'.

As noted by coda in the comment section, pattern mutators is now included in mootools 2.0.
PatternMutator is also the base of my kenta.AOP Class for Mootools that I'm going to introduce, and as a bonus I will show how to use kenta.AOP to create a simple Mootools Class Profiler.
What kenta.AOP is?
kenta.AOP is simple way to handle AOP in MooTools for debugging purpose.
In particular kenta.AOP handles method invocation by rewriting all Mootools class, allowing you to intercept these methods before and after the execution.
You can then use the event parameter to cancel the method's execution or hijack the method's return value.
kenta.AOP uses Mootools Events in a Publish-Subscribe pattern to let you write any modules you want.
In this post I will show you kenta.AOP.Profile to better demonstrate what kenta.AOP can do.

I wrote kenta.AOP as a little project to better understand patternmutator and AOP myself, but since it might be useful for other people I will share this snippet. piece of code.
What kenta.AOP is not? It is not a complete AOP Framework. In particular kenta.AOP can't handle property access and it doesn't perform exception handling by design; it also overwrites all MooTools class methods, so I advise against using it for production-code :)

the complete code of kenta.AOP is here:
kenta.AOP provides a global AOP object that fire two events: 'pre' and 'post', that you can use to listen and hijack methods.
Even if kenta.AOP listens all Mootools class method, it is designed to fire only if the Class has a 'Aspect' property

I guess you are wondering what kenta.AOP can be useful for, so here's a little example of how this code can be useful for debugging:
with an example:

Since Profiling don't require to overwrite the return value I will show you another example:

and another one in which we cancel the method execution:

MooTools private pattern mutator

UPDATE: I created a MooTools forge repository for Private. There you will find any kind of improvement ;) /UPDATE Not too long ago I wrote this gist to add a sort of private properties / private methods to MooTools 1.2.x:

As of MooTools 1.3 this gist won't work anymore, but I've wrote another one as alternative, it requires Mark Obcena's PatternMutators.js that you can find here: keeto.PatternMutators.js:
How it works?

In the first version, the one for the 1.2.x branch of MooTools, if you Implements Private, what happens under the hood is that it create a property using MooTools $uid to get a unique-id per istance on a not-accessible outside of Class.Mutators.Private function, then it rewrote all the method of your instance passing the associated property as the last parameter of your function so that you can use it to store/retrieve private properties or even methods.

Since there's no way to automate the cleaning of all the objects/methods you can add, it need also to add a '~' method that you need to call on your destructor so it will not leak memory. I decided to use this ugly syntax: ['~']() because it need to stand out of your code, in a way to remember you that you are using an ugly hack to create privates and because is easier to remember something so strange ;)

For the 1.3 and upper branches of MooTools(yep, still work on 1.4.x) I decided to use a different, not compatible, way to achieve the same objective, so I based my mutators on keeto's patternMutator, for a number of reasons, basically cleaner syntax, re-using of existing code (keeto's one), and only methods marked with 'private' are now overwritten. You can see an example right here:

The code is slighly different, instead of Implements:[Private], you have to explicity mark the method you would like to use private properties or methods by adding 'private ' ahead of your method name, but other things remains unchanged.

Post Mortem of a big js project (Part I)

Well, it seems ages since the last time I updated my blog, I really think is time to shove some dust off my blog.

Where did I'm vanished?

I was really busy on a project, in which I put lot of effort, I'm now to a point where I can consider the project to be quite stable so I can finally relax and return back here to write something about this.

I thought it was a good idea to write a post-mortem of this project.

Well. Let's start.

I was told to rewrite a really complex application originally written in vanilla javascript, because it needs to change it's UI.

After a little talk to the original application writer we comes to the conclusion that we can't only extend the old application to support the new UI but we need a total rewrite from scratch.

We only had something like 6 months to rewrite an application that was written in the span of 3 years with lots of features, in the meanwhile we even need to introduce more feature that wasn't expected to be introduced 3 years ago.

We immediately thought that we need to plan ahead what we will have to develop.

So we split the project in 2 big parts, the front-end and the back-end using an "MVC/MVP" approach,
in this way while he was concentrating on his parts, I could developing the new UI.

Both of us were sure that we needed to use a framework or a library to ease our work.

So we start to seek for the framework / library that was better suited for our needs.

He was quite sure to take jquery, but I was confident that we needed a better way to write our code, because, after all, it was one of our biggest problem.

The old application teach us that it was extremely important to write our code in a future proof way.

So, since I saw the benefits of good Object Oriented in my C# experience, I thought that we needed something that could force both to write more reusable code, enforcing the Object Oriented way to write javascript code.

With OO code we could have easily apply the TDD techniques that we both wanted.

After this considerations, It was pretty natural to me to follow the MooTools path, and I can tell you now that was a wise choice :)

Immediately after we started writing our firsts objects we feel the needs to automatize some tasks, like the merging of our little class file into a big script.

So I start to wrote the tool (a c# page) to merge together the classes, and to run our JSSpec page.
In the process of writing this page I included JSCoverage to made the code coverage of our tests, and I think this move was really smart, because we discovered that JSCoverage fails if it finds a syntax error in the code.
So technically it was as if we had a javascript compiler, that tells us that something was wrong even before running the page, not only that but it was amazing because JSCoverage returns the row where the syntax error was founded!

With a few tools we have TDD, BDD, Code coverage and syntax error applied to our js project. Marvelous.

Speaking of tools I found mootools really handy when we need to do a profiling of our application, it was as simple as writing a mootools mutator (https://gist.github.com/570711)

... but I'm seeing that this post is becoming too long, so I think I will continue it another day. bye ;)