Feb 17 2009


Writing Mootool Classes. Things I’ve learned.

Category: MootoolsTags:

With the release of my demo last week I have had many requests to make a public API. In the process of doing so I have run into a lot of things with classes that I haven’t encountered before. This has led to quite a bit of frustration because of my lack of understanding in properly using the framework. In hopes to save someone else time, below is a list of tips that may help you from making the same mistakes as I did. This list mainly applies to developers that are trying to create reusable classes. If you’re developing classes that wrap application behavior most of these gotchas don’t apply.

1) Using Jan’s Binds mutator can save a ton of time. When dealing with Classes that extend other classes execution order becomes critical. Binds can take a lot of this worry away.

2) When developing an abstract class that other classes can Implement even if it has options do not include ‘options’ in the class. When Implemented it will blow away your previously set options. Fun times.

3) Extends and Implements do not play well together when the base class, extended class and the implemented class all have initialize functions. I might be doing something wrong here but it looks like the Implement class always wins, and you loose access to ‘this.parent()’.

4) Keep track of your events! Make sure you have the ability to detach them. Again Jan’s Binds can help with this.


Jan’s version of bind doesn’t work in 1.2 Check out Aaron’s which does.

Aaron write:

The key to Implements is to think of them as add-ons, not inheritance. It would be like having a mixin for your car that adds wheels. If your car had wheels, you wouldn’t need it. So “Implements: Wheels” adds wheels. Classes that are meant to be mixins shouldn’t have any members that are already in use (like options or initialize). This is different than Extends. Extends in our car analogy would be the Model T followed by the 57 Corvette. Corvette inherits from Model T numerous things and adds additional items and can refer to elements in its inheritance chain. But Model T, Corvette, and Ferrari all Implements: Wheels. If you Implements: Wheels onto Model T, you don’t need to do it to Corvette and Ferrari, because they inherit from Model T.


4 Responses to “Writing Mootool Classes. Things I’ve learned.”

  1. Guillermo Rauch says:

    With the way Implement works until 1.2.X:
    - I don’t see a valid reason to ‘implement’ an initialize method (3)
    - The behavior of implementing a class wiht ‘options’ is the expected one. It $extend’s, wheraes Extends $merge’s

  2. nwhite says:

    I agree with you. Some of this design theory isn’t documented so I’m learning the hard way. I actually didn’t want to use Implements in some cases I wanted to Extend multiple classes. The framework only allows one. For now.

  3. Chris says:

    Extends makes it possible to subclass another class while implements makes it possible to copy over the methods of classes. Extends exposes a “this.parent” method to all the subclassed methods

  4. nwhite says:

    Chris, I agree and understand all this. This is normally not an issue when writing classes for your own applications as stated above. The problem comes from the design when you start abstracting pieces out the Extend/Implements become a bit tricky. I will illustrate in the near future.

Leave a Reply