MooTools 1.2.2 and the New MooTools More
Written By Valerio Proietti, on Thursday, April 23rd 2009, 7:53pmToday we’re releasing two goodies for you: MooTools 1.2.2 and the new MooTools More (1.2.2.1).
Core
MooTools 1.2.2 is a mainly a bug fix release but it also includes an almost entirely new Class.js. The reasoning behind this is that the old Class.js didn’t play nicely with some advanced usages of this.parent() present in the new MooTools-More. We already had the script ready and tested in the MooTools 2.0 branch so we simply “backported” it to 1.2.2. Other than providing the parent fixes, the new Class also features a much more robust inheritance model, especially when dealing with objects.
For example, the objects you implement now in a class are merged if an object with the same name is found in the class prototype:
var Animal = new Class({
options: {
color: 'brown',
says: 'hissss'
}
});
Animal.implement('options', {says: 'meow'});
// Animal.prototype.options is now {says: 'meow', color: 'brown'};
This is especially useful when overriding default options in classes, such as Request.
Another object-oriented feature we introduced is that now sub-objects are actually inherited Parent-to-Child. If you implement a new option in Animal, then Cat, which is a subclass of Animal, will get the new option as well, and so will every instance already existing. An example:
var Cat = new Class({
Extends: Animal
});
var kitty = new Cat();
Animal.implement('options', {nu: 'one'});
Cat.prototype.options.nu == 'one' //true
kitty.options.nu == 'one' //true
This obviously also applies to methods.
Additional changes to the MooTools Core in 1.2.2 are mostly minor bug fixes.
More
One of the new features of MooTools-More, since the last RC, is that it is now possible access the previous state of overwritten methods of classes through Class.refractor. An example:
var Cat = new Class({
energy: 0,
eat: function(){
this.energy++;
}
});
Cat = Class.refactor(Cat, {
eat: function(){
this.previous(); //energy++!
alert("this cat has " + this.energy + " energy");
}
});
This functionality allows users to integrate seamlessly with existing classes, and add to existing methods without the need to subclass.
We’re considering some way to make this behavior more generic for a possible inclusion in MooTools-Core 2.0.
The first RC of MooTools-More produced a lot of feedback and contributions that we’ve integrated as we prepared for our full release. Following this full release of the new MooTools More plugins, we’ll begin adding new features quickly and regularly with what we hope will be biweekly releases.
April 23rd, 2009 at 9:02 pm
Nice, will test this first thing tomorrow! Thanks for all the hard work guys, MooTools saves us a lot of time.
April 23rd, 2009 at 10:05 pm
Yay, can’t wait to test it tonight. Thank you!
April 23rd, 2009 at 10:19 pm
Always great to see an update!
I downloaded both (core and more, uncompressed & all options selected) and there are some illegal characters in the more file.
Moreover, when I replace the mootools core/more 2.1 files with these, my application doesn’t work anymore. Are there any changes (Class.js) changes that I’m unaware of??
April 23rd, 2009 at 10:48 pm
Awesome guys.
One question. Has the new mootools been tested against Safari 4 beta?
Last time I checked, Class.refactor caused Safari 4 to crash big time. (Don’t know if this is an issue with Safari, mootools, or both).
Keep up the great work!
April 23rd, 2009 at 10:49 pm
Sweet progress, now we’re cooking
April 23rd, 2009 at 11:01 pm
@Ben, we ran all of it through jslint and didn’t get any errors. Can you elaborate on the trouble you’re seeing?
@Mani, the Class.refactor things w/ Safari 4 are fixed by the new Class.js (Opera, too).
April 24th, 2009 at 1:17 am
Hi guys,
I just want to know if it is fully compatible with mootools 1.2.1 scripts?
Thanks for the good work!
April 24th, 2009 at 1:26 am
Great!
April 24th, 2009 at 1:44 am
Awesomesauce!
Thanks for your effort in making MooTools the greatest JS framework on the intarwebs :-)
April 24th, 2009 at 1:53 am
Very cool, guys!
April 24th, 2009 at 2:22 am
Looking forward to checking it out, and wish you best of luck with 2.0!
April 24th, 2009 at 4:59 am
Moo wrok guys. I was waiting for that release… Do you know if does the cdn on google api playground is yet updated ?
I’m using mootools and clientcide with google api playground and i wish it updatee alone whne you relaease a new version :)
nunzio
April 24th, 2009 at 7:28 am
Great going!!
This is even more exciting than the name change :)
April 24th, 2009 at 8:19 am
Good work! The refactor is crazy, but in a good way.
April 24th, 2009 at 9:15 am
nice job guys! comes just in time before I start on a new project. I just love the smell of fresh mootools in the morning :)
April 24th, 2009 at 11:07 am
@Adriaan 1.2.2 has no breaking changes, but if you’re using the Clientcide versions of scripts that moved into More, there are changes. I’m working on a compatibility release for today.
April 24th, 2009 at 11:20 am
Great Thanks!, I love MooTools any idea when will 2.0 be released? I just cant wait, and I really need the new language feature already xD.
April 24th, 2009 at 11:41 am
Nice work, guys. The changes to Class sound great!
April 24th, 2009 at 1:24 pm
@Aaron: I found out what is different now. I built my JS classes in a way that mimics how I built classes in Java/PHP, that is I specified class attributes outside of the methods:
I understand the change, and it can all be solved by declaring the attributes in the initialize method, so it’s not a major issue, however, it’s a change that made my code fail and it might happen to others :-).
April 24th, 2009 at 1:33 pm
IMHO, not a good update. Too much taken from Clienside. At least half of new features is not needed and thus no reason to make it available for everyone. I am a little disappointed.
1.2.1 version was perfect one. I only found interesting in More (out of innovations):
Class Section Date class URL handling
The rest (new features, classes, functions) are simple custom code that can be implemented by developers and I do not see reason to put them into Mootools at all. It is not used much mostly in rare cases. Clientside was doing its job perfectly but to put all that into Mootools ????
April 24th, 2009 at 1:43 pm
@Asgaroth we’re aiming for a summer release of 2.0
@ksamdev Sorry you’re disappointed. The overhaul of Class.js is a big deal as it fixes issues in Opera and Safari but more importantly more closely preserves prototypal inheritance. This is a big improvement, though a subtle one.
As for -more, the key thing here is that MooTools is going to start growing it’s plugin library dramatically this year. This first batch is just that - the first batch. Moving the Clientcide libs over to be in MooTools means that they are maintained by more than just me which improves their quality and also means that bugs get addressed more quickly. Expect to see more Clientcide libs move over.
But also expect to see new contributors in our group adding new plugins. Just as I’ve written and released dozens of plugins on Clientcide, you should expect to see other MooTools developers sharing their plugins in a way that they previously didn’t. This release may not excite you, but the change in direction should.
April 24th, 2009 at 1:45 pm
@ksamdev I understand why you might feel that way. However, more isn’t what it used to be: More is now some sort of a repository for official and outstanding MooTools plugins written by MooTools developers. And I hope we all agree that more plugins === good, and more good plugins === better.
It’s not into MooTools core, It’s in MooTools more (http://mootools.net/more). MooTools core is the same as always (http://mootools.net/core)
April 24th, 2009 at 1:58 pm
Congrats on the release. Will you be announcing a process for submitting to More in the near future? I have quite a few plugins that I would eventually like to put forward to be considered after I refine and release them. There are also a lot of other worthy plugins out there that I would love to see in More.
April 24th, 2009 at 4:23 pm
@Viruosi, see this link: http://wiki.github.com/mootools/mootools-more
April 24th, 2009 at 4:23 pm
I agree that Core is the same (not counting bug fixes) and only More was extended.
But mootools should be quite restrictive IMHO to plugins. In principle according to my understanding a parallel with other languages can be drawn, say with C++.
Mootools Core - is like language itself, say C++, Objective-C, PHP, etc. One may object that JavaScript is a language and Mootools is a framework but Mootools Core completely change the way scripts are written. It looks more like an extension of JavaScript, making latter as a complete language.
Mootools More - is a framework like STL in C++, Carbon, Cocoa in Objective-C, Boost in C++, Qt in KDE.
Think for a second about a question: why are this frameworks so successive nowdays? B/c they have only necessary features included, say basic Widgets, Classes for Text processing, I/O system, etc. Nothing else, nothing that can be used only once in a long while. They all very well thought through. Any successive and revolutionary things are simple and easy like Mootools Core.
I can see that Mootools More in 1.2.1 included only vital items. But version 1.2.2 has some of unnecessary functions that in principle are not needed there IMHO, say Forms Validator, Request Periodical, OverText …
April 24th, 2009 at 4:52 pm
@aaron - Thanks. Is there any sort of objective criteria for something being “well-written” that we can have as a guideline, or at least an explicit enunciation of the general design principles, just so we’re all on the same page? I know that we can all look at the code, but spelling things out might help to minimize confusion. I agree with ksamdev in that the standards for plugins should be high because I think that it reflects on the framework as a whole. At the very least, I would vote for rigorous testing in all browsers for each plugin, which I’m sure is something that’s already being done. Perhaps plugins that haven’t had everything thrown at them yet could be given a beta label? I don’t have any problem at all adding a lot more plugins to More, though, just as long as they are high quality, because you only download the ones you need.
Also, has any progress been made on the Forge? I haven’t seen anything on it in several months.
April 24th, 2009 at 5:18 pm
@aaron: It’s awesome that the Safari 4 issues are resolved. Safari 4’s debugger + mootools will take javascript to the next level.
Thanks again to the mootools team for all your hard work!
April 25th, 2009 at 7:14 am
Hi, great news! I am getting following firebug error with my application: “Asset.extend is not a function”. Has anything been changed ? Any hints ?
Best regards!
April 25th, 2009 at 7:20 am
After looking into the new “Mootools more” I noticed that it used to be “var Asset = new Hash({…” and now it goes “var Asset = {…” which somehow breaks my code when trying to extend it.
April 25th, 2009 at 11:58 am
@Bob, Asset is no longer a hash (it doesn’t need to be). Just change your extension to do $extend(Asset, {…});
April 25th, 2009 at 1:20 pm
A great update, these updates fix behaviour of the MooTools Class object that were previously difficult (and somewhat lacking documentation). The Class.refactor method looks great to be able to abstract content and data processing (which I why I presume you have given the example you do) so I’m looking forward to benchmarking that with a view of implementing. Excellent updates!
April 25th, 2009 at 8:24 pm
Hey moo guys (and gal),
I picked up the latest mootools more release and it was throwing errors. Does it have to be combined with Moo Core 1.2.2 to work? I then tried to take only the includes I already had without extras and it still is borking… Binds seems to be coming up as a new dependency, could that be doing it? Maybe somewhere where I have extended things? Do you have a list of breaking type combos that could cause this?
April 26th, 2009 at 12:17 pm
Thnx aaron. Keep it up!
April 27th, 2009 at 11:47 am
Always a great thing to see Mootools move forward, especially when it comes to elegant enhancements.
Btw, is that a typo in the first sentence in the “More” section… “through Class.refractor” should read “through Class.refactor” ?
Thanks again for this great framework! Jacob
April 27th, 2009 at 9:23 pm
Does not work at all in IE6… almost as if mootools does not initialize… all MT functions fail/give errors.
April 27th, 2009 at 9:39 pm
@kovo: I’m sorry it didnt work out for you. However, we assure you MooTools does work in ie6. If you plan on being more specific, feel free to open up a bug report in the tracker linked in our homepage.
April 27th, 2009 at 9:42 pm
Thats fair. Sorry for being so negative. I know it does not help to debug. Im going to try and only load core.js, see if it fixes it. Maybe its a compatibility issue in More.js
April 27th, 2009 at 10:59 pm
Great news!
Very excited about the new class changes! Thank you all for your hard work!
April 28th, 2009 at 7:40 am
Great work guys and gals! I’m glad to see mootools more grow, the clientcide libraries were great but now with more eyes and hands working on them I’m sure they will get even better. Class.refactor is amazing stuff as well.
April 28th, 2009 at 9:12 am
I’m sorry to say that, but i’m a little disapointed, i mostly agree with ksamdev, i like mootools because it provide only what i need (and a little ‘more’), i regret a “true” namespacing/repository hadn’t be set up to deal with 3rd modules. I prefer a lot insert dependencies for mt://ClientCide/Class/Class.Bind rather than seeing the “official” More heriting Application specific code, (forcing Localization is a real bad idea, for example) - A.N. that’s still excellent work, that was never my point.
April 28th, 2009 at 9:33 am
looks like great improvements.
@ksamdev if you don’t like elements of More then you don’t have to use them. plain and simple. Your comparisons of More being a framework itself is severely flawed. Use what you want and ditch the rest. That’s why it’s structured the way it is.
April 28th, 2009 at 10:34 am
@131 You must realize that this is just the start. The -more collection of plugins are plugins that the MooTools developers have authored that we want to share. They aren’t like -core which is required - you can’t use MooTools without using -core. But everything in -more is optional, and this is just the first batch. Expect to see new functionality added often. -core updates every 6 to 8 months, but we hope to iterate -more every two or three weeks, adding one or two new plugins as we go along. Hopefully we’ll end up adding one you like at some point.
April 30th, 2009 at 3:14 am
every function is wraped by Class.wrap. is that a right way? 1.debug will be very diffcult 2,it is very easy to cause memory leak.
April 30th, 2009 at 8:17 pm
@jay:
Yes.
No, as it’s not any more difficult than debugging a function that calls another function.
No, as the usage of Function:bind doesnt cause memory leaks.
On another note, we always wrapped class functions, it was just a little more convoluted in previous versions.
April 30th, 2009 at 9:25 pm
@kamicane : well,I don’t agree with the process for Implements. for example,if I implement the Options class,the class function(setOptions) is wraped twice by Class.wrap. On another note,_hidden is not used. I just want to know the benefit of class.wrap for Implements.
case ‘function’:if (value._hidden) return this; proto[key] = Class.wrap(this, key, value);
April 30th, 2009 at 9:31 pm
@jay:
I’m sad to hear that.
Obviously, that’s not the case. There’s a check in place to prevent that. If it actually did wrap it twice, everything would break up, and we would have definitely noticed.
If you have any ideas on how to improve further versions of Class, feel free to open up a ticket in lighthouse, or make a patch.
April 30th, 2009 at 9:48 pm
@kamicane There’s a check in place to prevent that
I am sorry.I can’t find the place for check that and prevent.
anyway,I absolutely invoke class.wrap twice when I invoke the function(setOptions).you can test it.
April 30th, 2009 at 10:02 pm
@jay:
I assure you we did test it pretty extensively.
Again, if you have a bug to report, please do so in our ticketing system. I get it, you dont like how MooTools works, but there’s nothing much I can do about it :)
May 1st, 2009 at 10:04 pm
Another object-oriented feature we introduced is that now sub-objects are actually inherited Parent-to-Child ?
previous version(1.2.1) also implement that. what’s the difference of the two version? thx
May 1st, 2009 at 10:34 pm
@007 previously if you implemented an object over another one it would overwrite it entirely. If you did:
and Animal previously had an options object, in 1.2, options would be overwritten, not blended with this new property.
May 3rd, 2009 at 3:08 pm
Hello
It’s always good to see progress, unfortunatly, “scroller” is not working very good with this new version… it doesn’t “stop” anymore here and on another page it’s not working anymore and I don’t know why. Uvumitextarea is not working anymore too, strange…
So I’m back to the previous release :-(.
May 4th, 2009 at 12:54 am
@lordpx, could you open a ticket with details?