Maybe it’s in the definitions we use. To me, a class implies a batch of data and the set of methods that work on/with it, while this was simply a set of methods that worked on nodes of the DOM tree, therefore extending the existing class that worked on the DOM seemed the more natural way to go.

Yes, I saw the mootorials. I didn’t view that particular one because classes seemed to me the wrong way to go about it, but I did follow other links there, including the “30 days of mootorials” one. Nothing seemed like a good fit, so I started searching forums and looking around for a MooTools plugin that did something similar to what I was after so I could dissect it and learn from it.

While I failed in that quest, some discussions on the forums got me pointed towards Element, and I crawled the source code looking for how Element.Dimensions worked, as it seemed the most similar to what I was trying to do. That was my first mental model, and I went on building outward from there.

Your tweets helped, Aaron, but as I acknowledge above, often I didn’t know enough to know how to frame the question properly.

As one coming at it from the outside, I’d say MooTools has an S-shaped learning curve. It doesn’t take a lot of effort to do simple manipulations (I’d written a slideout site login tab in it, for example, with very little diffculty). But then the curve to go beyond that gets very steep (I’m expecting it to level off after that is climbed; most systems do, but since I haven’t climbed it yet, I can’t say for sure that it does).

Your “jQuery style code” example is one I would have termed a “javascript style code” example,as that sort of functionality is built into the language. I was writing javascript like that (where the results of one call are passed directly into a subsequent call and those results passed into another call, etc.) before I ever saw jQuery. (BTW, that highlights another piece of cognitive dissonance I ran into in the MooTools docs. That process is called “chaining” in every other OO language I know; what MooTools calls “chaining” I’d always known as “queueing”.)

Anyway, since my Joomla workload is increasing I’m sure MooTools isn’t leaving my toolbox any time soon. I’ll work through some of the tutorials and look around for your book.

It became clear to me during this process that MooTools is built from a viewpoint that is based on assumptions alien to me (such as creating a class to operate on data that is not contained in that class). Now, by itself different doesn’t imply either better or worse. But where that becomes a factor is the benefit needs to be proportionate to the effort expended, and what I hope I was clear about in this post is that is the only test that MooTools failed, and not any sort of a performance test. It just seems to me if I decided to switch I wouldn’t lose anything much, if at all, I just wouldn’t be gaining enough to justify the effort.

I couldn’t find a HOWTO to get me started. I tusked around for a while on the net and found several supposed tutorials on writing MooTools plugins, but none of them gave me what I needed to start with. They were all about adding classes to the framework, and that’s not what this was supposed to be doing.

Classes ARE MooTools plugins. Almost every MooTools plugin is a class. The only time you should implement things into native objects (like Element) are when you want to add a shortcut to those objects. It sounds to me like you were trying to write jQuery style code that works like so:

$$(‘div’).myPlugin().addClass(‘foo’).hide();

Where “myPlugin” applies itself to all the elements returned by divs. The right way to write such a plugin in MooTools is to… write a class. THEN, if you want a shortcut that applies that class to elements, you extend Element with a method that instantiates that class. Look at Fx.Tween in the MooTools core for an example of this. The Fx class family is where all the logic is, but myElement.tween(‘opacity’, 0, 1); is a shortcut implemented onto Element. This shortcut just creates an instance of Fx.Tween and activates it.

For what it’s worth, as the author of the MooTools book and the Mootorial (www.mootorial.com), I recognize that yes, MooTools has a steeper learning curve.

Did you see this page?

http://mootorial.com/wiki/mootorial/09-howtowriteamootoolsclass