jQuery conflicting with other libraries

[Andrew da Silva]

If you try to use Prototype, jQuery overrides the $(), or vise-versa.

Now the plugin can't switch jQuery's noConflict mode on, because the
rest of Habari's JS is still using $().

This is of course, somewhat major change, so it justifies this
thread...

http://docs.jquery.com/Using_jQuery_with_Other_Libraries

Of the above alternatives, $j seems intuitive...

[drzax]

This would be relatively easily solved if the Habari javascript used
the Module Pattern. There are other benefits as well to be gained by
using the Module Pattern, so maybe we should look at doing some
refactoring. This can probably actually be done very quickly.

For example in admin.js we would change:

var dashboard = {
init: function() {
...
}
}

to:

var dashboard = function() {
var $ = jQuery;

return {
init: function() {
...
}
}
}();

[Chris Meller]

I would much rather take drzax's approach than change the $() convention that most people are aware of. It's a little extra overhead, but that's fine by me.

If we opt to refactor the admin's JS, it would be great if we looked at splitting out some of admin.js into their own separate files, just to make it easier to manage and make individual pages lighter by only including what they actually need.

[drzax]

If there are no objections I'm going add a ticket in trac and start
tackling this.

S.

On Oct 20, 3:32 pm, "Chris Meller" <ch...@doesnthaveone.com> wrote:
> I would much rather take drzax's approach than change the $() convention
> that most people are aware of. It's a little extra overhead, but that's fine
> by me.
>
> If we opt to refactor the admin's JS, it would be great if we looked at
> splitting out some of admin.js into their own separate files, just to make
> it easier to manage and make individual pages lighter by only including what
> they actually need.
>

[Chris Meller]

Tackle away!

[Nathan Hammond]

Simon, just one additional suggestion for capturing the reference to
$:

var dashboard = (function ($){
.
.
.
})(jQuery);

The slight modification simply moves the capture of the closure one
step up in the call stack. That makes it inline with the jQuery
invention and, as an added bonus, I find it cleaner. For those
following this conversation I've included some background information
about why this is necessary in jQuery below.

Nathan

***

As a result of some of the defensive design work done by the jQuery
team, it became possible to have multiple versions of jQuery on the
same page. This provides a few neat tricks such as the ability to
support multiple versions of the jQuery API for different plugins on
the page, as necessary. Eventually though, one of the ideas is to be
able to remove jQuery from the page after instantiation. The idea is
to capture the reference to jQuery in closures where necessary, and
then remove itself from the page (!).

That is also the reason the jQuery variable needs to be caught in
closures for modules: to make sure that the object is always calling
the jQuery instance that it thinks it is.

[Tane Piper]

The other option is just to use the jQuery object directly, rather than
aliasing it to $. I do this in a lot of my code now as it pretty much
guarentee's compatibility.

--
Tane Piper
http://digitalspaghetti.me.uk

email/gtalk: ta...@digitalspaghetti.me.uk
skype: digitalspaghetti
mobile: +447815 101802
twitter: http://twitter.com/tanepiper

[Nathan Hammond]

Tane,
You should look out for the scenario I was talking about earlier where
there are multiple versions of jQuery being used on the page. In that
scenario, since the "correct" jQuery variable isn't caught in a
closure, you can possibly open yourself up to race conditions.

I'm aware that generally this isn't a problem, but I'm working on a
site right now where that is the case.

Best Regards,
Nathan

On Oct 23, 12:07 pm, Tane Piper <digitalspaghe...@googlemail.com>
wrote:

> email/gtalk: t...@digitalspaghetti.me.uk