1 Answer
1

The "value" attribute is not valid for a <script> tag; you're thinking of the Visualforce <apex:includeScript> tag. Choose one or the other; if you use the HTML tag then the attribute you want is "src". That's why you get the error; your script is not getting loaded, and thus "mCustomScrollbar" is not written into jQuery.fn (the [object Object] cited in your error is actually a jQuery result set object, which can't find a "mCustomScrollbar" property in its inherited jQuery.fn prototype if that script file didn't load).

The use of jQuery.fn.noConflict, and avoiding usage of the global "$" reference are both good practices -- however these should not be necessary under most circumstances, even in Visualforce pages. One exception is when you use apex's tab component, which unfortunately imports an old Prototype script that also wants the global "$" symbol.

Good catch, I didn't notice that when I answered. Also worth noting the script itself is poorly written and won't work with noConflict if the OP does end up using it without some modification.
–
drakoredFeb 1 '14 at 6:42

I just now viewed the script too, and while I agree the code is far from beautiful (to be fair I've written scads of code FAR worse than this in my time), it does properly protect the global "$" symbol through use of a wrapper closure.
–
mulvelingFeb 1 '14 at 6:54

@mulveling - You and I must be reading it differently then. If noConflict is run $ no longer points to the object now known as $j (in his context) and jQuery. So calling $ inside this plugin will do nothing. That was my point, not that it was going to overwrite $, but that it is a jQuery plugin and hence needs to be able to find the actual jQuery object rather than prototype or whatever else might be using the $ variable.
–
drakoredFeb 3 '14 at 17:59

1

@drakored - That is what the "(function($){ /* plugin code */ })(jQuery)" wrapper does -- it uses the global jQuery symbol, which is still valid after a noConflict(), and binds its value to the formal parameter "$", which is visible only to the plugin code -- so in there, using "$" is ok because it's not binding to the global "$", but to an outer argument that is defined.
–
mulvelingFeb 3 '14 at 18:12