Javascript: Allow compatibility with other libraries.

I think too, that it is really necessary to remove the use of the $()-function and write into the development handbooks, that developers shouldn't use the $()-function because there can be conflicts with other JavaScript-Libraries, but as long as this problem is not solved, I created my own version of Prototype where the $()-function is renamed to $ID(), so I can be used with Drupal 5 without having any problems. I made a compressed version too, which is available at my Weblog.

There's a lot confusion on this point, and I'd like to point out a more-ideal solution. The Drupal core, and any Drupal plugins, should use the native jQuery() function. Defining it to any other namespace (like $jq) will only cause any/all Drupal/jQuery code to become Drupal-specific; which is, generally, a poor solution.

Once the Drupal core is using jQuery() exclusively, the decision to use $() would then be left to the user; the same person who should be choosing to use Prototype or Mootools (or any other $-using library).

Additionally, any module that uses Prototype, or Mootools (or any library that explicitly overwrites Drupal/jQuery's $() function) should be re-written to use a copy of Prototype or Mootools that isn't so destructive (like the one posted by xhochy). In this respect, the JavaScript code of Drupal modules should be treated just like any other PHP module code (like completely overwriting, and breaking, a native Drupal function).

Finally, it is then left to the user, if they should chose to use Prototype, to simply call jQuery.noConflict() - allowing them to use Prototype's native $() function. While, at the same time, regular Drupal users, who wish to use jQuery's $() function, don't have to jump through any additional hoops in order to get started. But that's ok, because with this solution these two groups of users will still be able to happily co-exist.

Excellent points!
We should work along those lines.
The only little detail is that jQuery.noConflict() is not available in the older version of jQuery that currently comes with Drupal core (5.1).
Hopefully this will change in the future.

I found ca. 190 occurences of the $()-function in Drupal HEAD with the following command

find -name "*" -exec grep -Hn "\$(" "{}" ";"

Sadly not all occurences found by find are really $()-function-calls, some belong to a regular expression or are part of a binary file, I think that I will try to write a simple(4-10 lines) replacement script, that I would run on each of the file without those regular expressions. The other files(which cause conflict through regular expressions) have to be edited manually, but I think that shouldn't be a lot of work.

I think most important now is to add to a handbook(I don't know where it belongs) that core implementation should only use jquery() and not $() in future to give the user the choice of the javascript library he wants.

Ok here's my script(sry but it's in ruby but should be simple to understand) for the replacing of $() with jquery and the patch for Drupal so that $() isn't anymore used. The next step should be a upgrade to jquery 1.1.x.

Because only one file per comment can be uploaded here's the ruby script.

can you post the patch as a unified diff?

The "jquery_15.patch" should be an unified patch, or do you want the patch for prototype?

Perhaps I wasn't clear- "jquery_15.patch" does not seem to have been made in the unified diff format.

Please run diff as "diff -up" when making a patch: http://drupal.org/patch/create

ok, I made a new after the Drupal instructions, here is it.

And before it...

If i need to upgrade my Drupal 5.1 for a newer version... I will lose this replacements right? has someone know about what this will be solved on the future by the development core team? or a link about what the develompents pretend to solve this on future version?

On her last path, what is the version of JQuery?

Can you take me the source of replacement script?

Thanks!

Patch updated for HEAD.

Rather than bloating the code and hampering readability by peppering the code with 'jQuery', a closure could be used to alias jQuery to $ locally instead to keep the best of both worlds.

@Steven: I'm trying to use a script made with scriptaculous and prototype on Drupal 5.3, but I'm a JavaScript n00b. Can you please explain further how the closure approach would be implemented? TIA.

Marking as needs work per #15.

kratib: http://docs.jquery.com/Using_jQuery_with_Other_Libraries

@catch: Thanks. I read that page, but IINM that still means every occurrence of $(*) in Drupal core (and modules) must be replaced with either a closure or a new jQuery variable. Which is what the original thread is all about, right? Does the closure approach save some search-and-replace?

You just wrap the entire .js file in:

as has been proposed elsewhere.

That seems to work perfectly, with much less editing indeed. Note that in misc/drupal.js, one has to insert the

I wrapped the scoping anonymous function around all JS files in core and rolled this patch. All JS files are wrapped except for jQuery itself (obvious) and jQuery form (it already does the wrapping). This approach should be much cleaner (and saner) than replacing every instance of $ with jQuery. I've roughly tested this; the installer, drag-and-drop functionality, and sticky table headers are all working correctly.

A lot's happened since the patch. Needs a re-roll.

Not sure this is the exact same. All js files wrapped except jquery.js & jquery.form.js.

removed space in function ($).

Time is running short.. Wait for Drupal 7?

It's not like this patch (gasp!) adds new strings, changes the database schema, ports Drupal to Java, or anything big like that. Why are patches like these always so heartbreaking? :(

After applying #25, I added prototype.js (1.6) to drupal_add_js() so it gets loaded along with jquery.js. The result unfortunately was not optimal. Prototype immediately throws an error when the page loads and drag and drop throws an error on every drop. This patch missed all the places where we have inline javascript added to the page (in book, poll and user) which will no longer be able to use the $ function without wrapping in a special clause. (See http://docs.jquery.com/Using_jQuery_with_Other_Libraries if you haven't).

I updated the patch to fix book, poll, and user, but generally I don't think this can get into Drupal 6. For any module that has already been ported to Drupal 6, it will need to be wrapped in (function($) { }); to make it compatible with another library. That previously wasn't a requirement since other libraries weren't even pretending to be supported. It's something that would definitely be added to the Upgrading 5.x modules to 6.x page and an API change.

Sounds like this represents an API change, which makes it a clear 7.x feature. Sorry, kourge/dvessel. :(

Doh, forgot about the inline scripts. So 7 it is. No worries from me webchick, thought it was going to be a small enough change.

So does that mean the handbook page on converting 5.x modules to 6.x needs to be updated so that module authors wrap their JavaScript in a scoping function?
Also, I sort of doubt that inline functions need to be wrapped again. I think it may have something to do with the for...in loop construct; I'll investigate more on this.

subscribing

kourge: No, there's no need to update that document because this patch is an API change and thus won't be applied until 7.x. But it /will/ need to be documented in the updating 6.x to 7.x handbook page. :)

subscribing

subscribing.

http://drupal.org/node/170418 was duplicate.

Rerolled the patch. We definitely need this in D7. I added a call to jQuery.noConflict which removes jQuery from the $ variable. That means that all contrib module JS also has to wrap its code into (function($) { ... })(jQuery); to continue functioning.

Good move. This'll be a good enough motivation for maintainers. Breakage is the last thing maintainers want to happen on their modules.

Subscribing.

Hierarchical Select is now doing this: http://drupal.org/node/231576#comment-828004.

It's a super easy change, so I think there's no valid reason at all to prevent this patch from going in.

I agree, after John Resig chided us a little bit (rightly so) about Drupal's lack of wrapping the Drupal core code in these compatibility wrappers I did feel a little poorly about shooting this down for D6. Anyway, this definitely does need to happen with Drupal 7.

@kkaefer: Is there a good reason for adding this to jquery.js instead of drupal.js?

I agree with the decision to essentially "force" contrib modules to use the wrappers also.

not sure if this is rellevant to this post, but there is a problem with for and while loops in javascript in the latest version... very easily reproducable,

It's completely unrelated. If you think you found a valid bug, please post an issue at http://drupal.org/node/add/project_issue/drupal.