Got a question though… is there a way to get the returned value of the callback when using fireEvent?

After reading this article to understand more behind the scenes, I can definitely say I am pleased to have started learning this framework.

So, I definitely appreciate the work you and your team have done on MooTools, for the little parts of it I am using. And, I must say, the Class constructs are working pretty well for me so far. I am just getting into implementing my events-handling layer, and I hope to leverage what MooTools has to offer. No matter what, it has really helped me out and I am making great progress with JavaScript development that I thought would have been nearly impossible just a month or so ago. Regards.

@Houston SQL Server Developer You’ve got a few points here, but looking 2 years back from now, there’s a huge growth and improvement at the Mootools side of the line. It’s not really fair to blame Mootools for all inconsistencies of documentation, seeing that they put all there energy and free time into improvements, fixes, new documentation and plugins for the framework. They even kindly ask the community to back them up and help them if there are inconsistencies. They do anything for the framework to make the whole package a better present for the community.

Mootools was like a cow 2 years ago, but from the sideline I see the framework rapidly growing to a cow with a ribbon that can give whipped cream directly to the community :-)

Thanks again for brightening up Event handling!

Note that those are not screenprints, but embedded jsfiddles so you can play with the code yourself, run it and see what it does. I believe I added enough examples which are explained in the surrounding text.

What you’re saying about the on part is that it is inconsistent in the MooToorial, is something that might be true, however the MooToorial is a great resource with a lot of info, but is a little outdated and written for mootools 1.2. Also note that this about Class Events. To explain it once more:

it is onComplete when it’s used in the options property with the Options mixin. For everything it’s just complete. The examples in the MooToorial are wrong because they’re outdated. Though it is a Wiki and you can fix it. Besides the MooToorial is not an official MooTools resource like the docs. Furthermore we’re always considering and accepting changes to the docs, just look at how many little changes we made since 1.3.

So what I tried with the post is to explain more about events than the docs could do. And what you could do is to report inconsistencies at lighthouse, ask questions at the google users group, come talk at IRC, but don’t get angry alone and wast many hours, but rather ask so you’ll learn new stuff and we might see how we could improve our docs or where we should write about in the next blog post.

Well, that discussion talks about a “stop method” which is not shown or otherwise introduced in any code thus far displayed. The method you refer to shows only later… you first are able to see that code in the “Removing Events” discussion in the JSFiddle gizmo at the end of that next section.

Although this may sound trivial, it is the small oversights like this that will frustrate newcomers to MooTools. I have encountered all sorts of things like this in the MooTools mootorials and help pages, and it nearly convinced me to pass MooTools up in favor of a competing approach. Accurate documentation is just as important as the underlying technology if a framework is to be a truly useful framework.

I was also comparing the Events discussion in this blog entry to what shows on the MooTorial site at: http://mootorial.com/wiki/mootorial/02-class/01-class.extras

After doing so, my level of confusion just increases. That mootorial page even states: “In MooTools 1.2, Events starting with ‘on’ are still supported in all methods and are converted to their representation without ‘on’ (e.g. ‘onComplete’ becomes ‘complete’). If you reference the ‘on’ version (i.e. ‘onComplete’) it will still work, but this is deprecated.”…

But yet, I see the “on” prefix used immediately thereafter in examples; immediately after the statement that said “on” is deprecated, etc. Oh please… please… just bring some consistency to all this documentation and show only the preferred way to implement events so that I do not accidentally choose a way that no longer works with future versions.

I am trying to fully embrace MooTools, and I think it has a lot of potential for my needs; but, I am also finding inconsistencies and a lack of clarity in documentation and discussions are adding much more time to the learning curve and thus slowing my adoption of the framework. It would perhaps help quite a bit if you had your documents reviewed by someone not as familiar with the framework so that those things non-obvious (to outsiders) could be identified and corrected. Many of the issues revolve around ambiguity introduced by grammatical constructs that are not as precise as they could be - something a technical-editor (person) could help clear up. Just my thoughts.

element.addEvents({‘change’: doSomething, ‘click’: function() { this.blur(); }});