Coding convention for jQuery4CMSimple

[cmb]

Hello community,

the problems with jQuery integration in CMSimple extensions is well know to the authors of extensions: version and namespace collisions with other extensions using jQuery or another js framework.

A really helpful invention is the jQuery4CMSimple plugin, which will help to avoid problems with different versions of jQuery used by different extensions, because they all could rely on a single jQuery version brought by jQuery4CMSimple. But this only works, if all existing CMSimple extensions using jQuery will be rewritten accordingly and distributed ASAP.

in the following I'll try to summarize yesterdays discussion about using the jQuery Framework from CMSimple extensions. The discussions were spread over the following threads:
jQuery integration
[New Plugin] jQuery4CMSimple
New plugin: Pagemanager_XH
Pagemanager_XH 0.3
I will quote without refering to the appropriate thread.

But one problem remains: namespace collisions. So I want to propose that we all agree on a coding convention for jQuery4CMSimple with regard to $. This could be added to jQuery4CMSimple's documentation.

If you use jQuery, you usually use the shorthand $ instead of the full name of the function jQuery. But the $ collides with other js framework as e.g. prototype.js. To avoid this there exists jQuery.noConflict(). Calling this function will remove jQuerys definition of $ from the global namespace, so that you have to call jQuery instead. It even has a return value that you can assign to a variable of your choice, e.g.

Code: Select all

var jq = jQuery.noConflict();

if you prefer another name over jQuery. The definition of jQuery remains, so it could be used as an alternative name. (see below for more details on this)

Now the IMO important question is: shall we avoid the use of $ altogether, to allow inclusion of other js frameworks, or shall we postulate, that only jQuery shall be used with CMSimple?

But from my point of view the whole no.Conflict() thing is not needed, because I'll not prefer more than one JS-Framework on the same installation.

Although I am really convinced that there is absolutely no need to use more than one js-framework in one CMSimple installation, you can't rely on other plugin authors or users with a faible for all kind of plugins

Even if I fully agree that one js framework should be enough for a website, I think it's in the open spirit of CMSimple to allow users to do what they want, even if they want to include 100 different frameworks (the resulting performance problems will be their's).
So I recommend to not use $ at all; that is the most compatible way. If we agree on this solution, the call to jQuery.noConflict() could easily be added to jQuery4CMSimple.

Some of you may think: oh no, I have to rewrite all my code that uses $, or even worse: my code uses another jQuery plugin that depends on $. I can't use my plugin any more.

But thanks to js closures (and Martin, who came up with this idea) it is possible to avoid this problem, if you use:

Code: Select all

(function ($) {
    // your old code using $ goes here
})(jQuery)

But a minor question remains: shall every author of a jQuery4CMSimple use his own jQuery shorthand? Well,

But I have to admit, I have no idea what is the content of a, b and c and how much memory they consume

I want to add: and how much time they consume.

Until it's definitely clear, that the overhead of using noConflict() multiple time is absolutely negletable (it may seem so, because the code uses only 1-2 reference assignments, but I'm not sure if heavy cloning may happen behind the scenes, when other jQuery functions are called; BTW: I'm very knew to js), I suggest, the best is to avoid the usage of jQuery shorthands and use jQuery instead. The overhead of Martins renaming closure suggestion should be the same, and so should better be avoided unless necessary.

Perhaps an advanced Javascript programmer could clear up this point to me and others, please.

I'm really looking forward to read your thoughts on this, so at least a convention concerning the use of $ could be found. The use of additional renaming of jQuery finally is the authors decission.

Regards,
Christoph

[cmb]

Hello Jerry, hello Holger,

I respond to posts from http://www.cmsimpleforum.com/viewtopic. ... &sk=t&sd=a.

It seems that jsTree doesn't wrap its code properly

I still guess, that it's so, but on reworking the js init output, I found, that perhaps I was not wrapping my code properly! I'll check that. But Martins suggestion can be the solution for such cases.

But Pagemanager and Newsbox Rotator can now be installed in the same cms.

Good to hear

It's possible to replace $ with jQuery without no.Conflict() -
BUT only when jQuery is loaded as the first framework!

It's my understanding that jQuery is always available (with or without a call to noConflict()). noConflict() affects only $ (so other frameworks can have it for themselves), and it's return value can be stored in a var, to work as another shortcut (e.g. jq). I'm quite sure about that.

But please, could someone with better JS skills than me, bring light to this?

I've already changed Pagemanager_XH 0.3's code, to not use the noConflict() return value. IMHO it's not necessary. But I have kept the noConflict() call, because it might avoid clashes with other libraries, and as a debugging aid for me.

Christoph

[Martin]

Hi,

maybe I don't understand part of the discussion. Isn't it basically very simple? As we want to keep the possibility to use, let's say prototype, as well, we have to make sure jQuery is loaded first (and the latter loaded framework might take over the $()-function). So jQuery4CMsimple just would have to prepend it to $hjs. No need for noConflict().

Of course, as soon as someone includes prototype e.g. we can't use the $()-function in our jQuery-code anymore. (That means, we have to use jQuery() or (function($) { /* your code in here might use $() */ })(jQuery)).

But isn't that something we should do anyway to avoid clashes with other framweorks or incompatibiliy with other plugins that do call noConflict()?

Martin

[cmb]

Hello Martin,

thanks for your reply.

So jQuery4CMsimple just would have to prepend it to $hjs

Another plugin could prepend the inclusion of e.g. prototype.js to $hjs after that

But isn't that something we should do anyway to avoid clashes with other framweorks or incompatibiliy with other plugins that do call noConflict()?

+1

I like to simply always use noConflict(), to avoid the many clashes as possible. And that could be done by jQuery4CMSimple in function include_jQuery.

Code: Select all

$hjs .= "\n".'<script type="text/javascript" src="'.$path.'"></script>';
$hjs .= "\n".'<script type="text/javascript"><![CDATA[jQuery.noConflict();]]></script>'; // insert this line
define('JQUERY', $plugin_cf['jquery']['version_core']);

So all plugins authors using jQuery4CMSimple must adjust their code accordingly, and plugin authors who use other frameworks, can use them (as long as they're not multiple plugins using different version of prototype.js included ) IMHO simple solution for best compatibility.

Christoph

[Martin]

Another plugin could prepend the inclusion of e.g. prototype.js to $hjs after that

Of course - you can always write incompatible stuff But is there any plugin that does so?

I like to simply always use noConflict(), to avoid the many clashes as possible. And that could be done by jQuery4CMSimple in function include_jQuery.

I thought about that, too. But I don't think, it is a good idea: It would kill all "old" jQuery integrations that use the $()-function. And it is simply not necessary as long prototype e.g. is not included. A plugin that uses prototype might call jQuery.noConflict() if it needs to ...

Martin

[cmb]

Hello Martin,

But is there any plugin that does so?

Good Point. Currently not AFAIK, but didn't you propose the jQuery4CMSimple should do it. When it does, there is one. And then another author might find he could do that too.

A plugin that uses prototype might call jQuery.noConflict() if it needs to ...

And if it does, the other mentionend plugin would break (if both are working on the same page).

The problem with old jQuery using plugins could be managed IMHO, cause Holger told us (sorry, can't find the post ) that there currently are only 5 jquery plugin developers -- all active members of the forum. And the fix is easy.

And one thing about old jQuery plugins is: they were not compatible either! Wasn't that the reason for jQuery4CMSimple's birth? If someone uses a jQuery4CMSimple plugin and an old jQuery plugin on the same page, that might not work.

Christoph

[jerry]

I found a toc, making use of jQuery and it worked fine with lightbox. I didn't notice it before I tested this site with a plugin built around jQuery. Then there is already some old jQuery code in use with CMSimple.
I have 2-3 plugins that use lightbox + prototype, and right now I have no idea how to replace lightbox with jQuery. So I have no plans to rewrite them right now. Moreover, they use both a rewritten version of the lightbox where images are resizing on the fly when the browser window is resized and I would like to keep this option (at least as an option). I don't remember that I've seen it work just as well in jQuery. The conclusion is that jQuery and prototype.js will coexist a long while yet.

And so we return to noConflict call. Newsbox Rotator is designed to run from the template and thus is always present when other plugins are running. Furthermore, I also have an ajax based image replacement in template which I am considering rewwriting to a plugin based on jQuery. This is already 2 calls to noConflicts with current jQuery4CMSimple. So the idea of integrating noConflict in jQuery4Cmsimple sounds reasonable. But it doesn't seem that several calls to noConflict give any visible overhead so I can live with both solutions.
jerry

[cmb]

Hi Jerry,

I think it's important to hear your point. Other developers said, that more than 1 js framework on a single website is not reasonable. I think it is some avoidable overhead, but as plugins are plugins, the user should decide, what he installs. And because we could do let that happen without conflict (thanks noConflict() ), I think we should let it happen.

But it doesn't seem that several calls to noConflict give any visible overhead so I can live with both solutions.

The problem is IMHO: if we do not put noConflict() into jQuery4CMSimple, the effort of jQuery4CMSimple will be partially useless!

Consider two jQuery4CMSimple plugins should work together on a single page. Plugin A uses noConflict(), plugin B uses the $. AFAIK this will clash, cause when A has called noConflict(), B cannot call $ anymore, because $ is deleted from the global namespace. If B wraps all it's code so that it doesn't call $ globally, it could equally have called noConflict(). But why leaving the plugin developer the freedom, to provoke further incompatibilities?

Christoph

[jerry]

But why leaving the plugin developer the freedom, to provoke further incompatibilities?

That's a point. Freedom to fail . I agree that noConflict as a part of jQuery4CMSimple is the best solution. Right now I can't se any disadvantages. But I'm not expert in inegration of various scripts.
jerry

[cmb]

Hi jerry,

But I'm not expert in inegration of various scripts

Neither am I. Or to say it more clearly: AFAIK you have much more experience in this regard than me.

What's the opinion of other developers?

Christoph