Mootools compatibility mode

[nwhite]

Just exploring an idea here. I know its been brought up before and shot down but I it doesn't hurt to try ;)

The only thing I am trying to achieve with this concept is to remove the dependency on $().

When you attach mootools to a page what if a query string was added

<script id="mootools" type="text/javascript" src="mootools.js?compatibility=true"></script>

The only cravat is a standard id would need to be established for the mootools script to find its own query string. The other option would be something like this:

<script type="text/javascript">Mootools_Compatibility = true;</script>
<script type="text/javascript" src="mootools.js"></script>

By default the core Mootools internally would be changed to replace $() with $m().

If compatibility mode is off $m() is copied to $() globally.

Window.alias('$m', '$');

If compatibility mode is on, a closure is created around Native or Class to expose $m() as $().

In the standard download I count 22 places where $() is used. If this closure method is used, I believe only the domready code would need to implement $m() instead of $().

Using this method all Classes regardless of using $() or $m() would work.

I believe this would solve a large majority of the compatibility issues Mootools has with other frameworks.

[Iván N Paz]

What about the prototyping of native elements?????

That conflict would still exist... wouldnt it?

[nwhite]

Prototyping? You mean using Implement or Extends.. No..

I'll take a stab at getting a working version up.

If anyone can shoot this idea down, please don't hesitate to do so ;-)

[Iván N Paz]

Hi Nathan

No, actually I "miss-expressed"... When I said "prototyping" I meant
"Altering the native elements, such as String, Array, etc..."

Would that be possible to overcome as well???

Cheers
Iván

--
◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦
www.ivanicus.com

[Tom Occhino]

Nathan,

You are missing a seriously important fundamental concept of
MooTools. MooTools enhances the JavaScript language by augmenting
methods to the native objects' prototypes. Any other framework that
does the same, or has anything else conflicting in that regard will be
incompatible. (Think Prototype) On top of that, there are waaay more
functions, classes, and objects in the global namespace. It's much,
much more than just $.

There is no way to create a MooTools compatibility mode, without
completely rewriting the framework, (damn near every line of it), and
making everything use generics by default, everywhere. Prototypes
could then optionally be applied. Instead of [1,2,3].each(fn), we
would have to use Array.each([1,2,3], fn) everywhere. I repeat, it
will never, ever be possible to make a MooTools compatibility mode
with the code in 1.x.

We could rewrite the framework from scratch to do pretty much exactly
what base2.js does, (as described above) but Dean Edwards has already
done a truly fantastic job with this. If we ever get into developing
a moo2, it would probably be very, very similar to base2.js, and might
even support a 'compatibility' mode; but don't hold your breath.

Check out the MooTools source code, the base2 and jQuery source, and
do a little more research if you don't fully understand what the issue
is. Post back here if you have any more questions about why this
isn't possible with frameworks like MooTools and Prototype.

- Tom

ps: @Iván, one question mark (?) is enough!

[Iván N Paz]

1 "?" wouldn't convey my concern/intrigue on this :-P

[nwhite]

Tom,

I realize anything using the prototype chain is doomed to this fate. While it would be next to impossible to create a compatibility mode between Mootools & Prototype it would however be theoretically possible to do so with a namespaced framework.

I guess I need to clarify my goals and expectations. I apologize for the title of the post, its has an element of sensationalism ;-) I never expected nor thought it was worth pursuing a compatibility level that would recreate another frameworks API with mootools.  Nor was it my goal or focus to even worry or deal with other prototype based frameworks. My goal was to try and make Mootools peacefully coexist with other namespaced frameworks, particularly JQuery.

I use Mootools on a daily basis and I am aware of all the complexities you pointed out. At the same time I have been required to be familiar with JQuery. I believe it was Jan that said earlier "that it is not an optimal solution to have two frameworks coexisting". The extra overhead, the duplication etc all take away the advantages. I do my absolute best to avoid even finding myself in a situation where this might happen. I also feel that if such a solution existed it should not be supported by Mootools as the levels of technical issues multiply. It is best to have someone leave and focus on a single framework. Rather then getting tied up in knots with two frameworks and javascript. So far I hope were on the same page ;-)

I brought this up because I have had experience making JQuery and Mootools code running in the same page. Its not pretty but it is possible. I apologize for bring this into open discussion as it will only result in headaches. With the "holiday" I had too much time to ponder the post about Wordpress plugins using Mootools while facing the Jquery dependency.  I love Mootools, I hate touching anything else and I thank you and the rest of the team daily as you make my day of coding that much easier and enjoyable.

I will try and refrain from such radical hypothesis testing in the future.


Nathan

[nutron]

My 2 cents here:

1) Everything Tom said and everything Nate said, I agree with. You shouldn't run two frameworks. MooTools isn't trying to be compatible. Yada yada. Prototype frameworks can't play nice no matter what, etc.

2) That said, academically I think there's an easy way to do this: closure.

(function(){

 //ALL OF MOOTOOLS

 //ALL YOUR CODE

})();

It's not the same thing as having a version of MooTools that plays nice, but it would work.

You could allow methods to "escape" the closure, but this would be more tricky:

var MT = {};

(function(){

  //ALL OF MOOTOOLS

  MT.$ = $;

  MT.$type = $type;

  MT.Drag = Drag;

  etc.

})();

MT.$('foo');

Yes, methods like $ need $type, but those are available to $ via closure. This would work, no?

On Mon, Oct 13, 2008 at 11:42 PM, Iván N Paz <ivannpaz@...> wrote:

1 "?" wouldn't convey my concern/intrigue on this  :-P

>  ps: @Iván, one question mark (?) is enough!

The MooTools Tutorial: www.mootorial.com CNET Clientside: clientside.cnet.com

---

View this message in context: Re: Mootools compatibility mode
Sent from the MooTools Users mailing list archive at Nabble.com.

[Tom Occhino]

it would be done like this... 

var MT = (function(){

// all of MooTools

// return some object containing MooTools functionality

})();

This is basically what Yahoo does everywhere, and the whole premise behind jQuery, a single object in the global namespace.  Again though, that "all of MooTools" line wont exactly work, because we use our global collections and native prototypes throughout.  Anywhere you see a MooTools method on an Array, String, Number, etc would have to be changed to use generic functions instead, so this kind of defeats the purpose of an Object-oriented coding style... 

[nutron]

Yeah, I meant that it would clean the global namespace, but wouldn't clean the Native extensions. This would make MooTools play nice with jQuery, Yahoo, and Dojo, but not Prototype.

Again:

1) Blah blah bad idea, you shouldn't use two frameworks

2) But totally doable

You're right about the code example below of course; much cleaner.

[Bryan Swift]

is there a reason you can't use jQuery's noConflict method?

I guess I'm wondering why you're trying to namespace parts of MooTools when jQuery already has the built-in ability to restore the $ function to whatever it was before (or free it up if it was empty) via jQuery.noConflict()

[nwhite]

While Jquery offers a noConflict method some plugins don't support it. In addition if you want to to inject Mootools into a page after Jquery you can't. Think GreaseMonkey.

[Iván N Paz]

Even if that would open a myriad of new appliances.... I prefer
sticking to just one framework, and implement on it, anything you find
usable/cute/cool/etc in others... so far, that has proven to be the
best option....

1 Framework to Rule Them All

;-)