Coding convention for jQuery4CMSimple

[Holger]

Hmm, to be honest, I don't understand all that problems .

In the past - before jQuery - it was just impossible to have more frameworks together.
Now jQuery provides no.Conflict - and that should be the reason making things such difficult?
JQuery, prototype, mootools? Everything on the same page?

Adding no.Conflict() by default will break all existing stuff.
And remember, not only Plugins - it'll break every script a user has added to his site content too.

So I think it's not a good idea to add no.Conflict() to jQuery4CMSimple.

For a "normal" jQuery-based Plugin, a developer should use "jQuery" instead of the $ shorthand.
How to do that, was posted here more than one times, e.g.:

(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()?

YES! And that's the only thing to do - IMHO.

I have 2-3 plugins that use lightbox + prototype, and right now I have no idea how to replace lightbox with jQuery.

If you want to provide such plugins, you should take care if your code breaks others.
You had to do that (and you did that) in the past too - but now jQuery4CMSimple can help you a bit:
just check, if the plugin exists and include jquery before your own stuff. If really necessary, use no.Conflict() with all it's disadvantages.


I rewrote some of my own stuff for testing purposes to use jQuery() - just a few changes in the code.
Now it works together with other libraries and no.Conflict() (if you do it the way above).
To me it seems to be simple...

So the only code convention / proposal should be:
don't use '$' - use jQuery() or (function($) { /* your code in here might use $() */ })(jQuery))

Or am I so wrong here???

Holger

[cmb]

Hello Holger,

thanks for your reply. Your opinion is probably the most important one as you're the developer of jQuery4CMSimple.

Or am I so wrong here???

No, I think you're not so wrong. But my point is: don't let the developer using jQuery4CMSimple leave the freedom to decide, if he uses noConflict() or not. If he writes his code as you suggest, everything is fine. But if he chooses to not conform, his code might clash with other (well written, as I might say) jQuery4CMsimple using plugins. And so the problem might continue.

If the developer is forced by jQuery4CMSimple calling noConflict(), to write his code accordingly, it is IMHO better.

Adding no.Conflict() by default will break all existing stuff.
And remember, not only Plugins - it'll break every script a user has added to his site content too.

Yes, that's right. But if a single plugin on this site will call noConflict(), the existing stuff might break too.

So the only code convention / proposal should be:
don't use '$' - use jQuery() or (function($) { /* your code in here might use $() */ })(jQuery))

Well, that's okay for me too on further thought, because

You're advised to use only this plugin together with all your jQuery based plugins for CMSimple from now!

is only a proposal. Not every jQuery using plugin developer might do it.

So I will test my plugin's code with noConflict(), but remove the call for the distribution.

What's the opinion of the other jQuery using extension authors, e.g. Gert and webscientist?

Christoph

[Gert]

Ok, here is my opinion:

1. I think, every plugin developer, who uses jQuery for his plugin, should load it by jQuery4CMSimple. That's why Holger has made it and why we have decided to put it to the standard download of CMSimple_XH.

2. The best way to do that is inside the main function, so jQuery loading is active only if the plugin is called in the content. Ok, maybe the plugin-call happens in the template ... so what, it also should not be a problem with jQuery4CMSimple.

3. Every developer of CMSimple extensions should read the developers manual before, it's available in German and English: http://www.cmsimple-xh.com/wiki/doku.ph ... gins:start

4. If the plugin developer have the choice between several JS librarys - he should choose jQuery. So I have done it by the step from kissGallery to FotoGalerie_XH, even if there alternative MooTools still is possible. Default is jQuery with jQuery4CMSimple.

CMSimple_XH is a small one admin CMS with a small development team, and it should remain so. We don't want to have a mess like WordPress or Joomla.

That less than 10 developers of core and plugins should find agreements, making conflicts improbably.

[Holger]

Yes, that's right. But if a single plugin on this site will call noConflict(), the existing stuff might break too.

.... and the user knows one minute after the installation why / what causes the trouble and removes the incompatible stuff again .

[cmb]

Hello Holger,

okay, okay, I will accept your proposal unless other developers will protest against doing that. For me, this case could be closed, as soon as the jQuery4CMSimple documentation will be updated accordingly. Or is it happened already

But one last word:

... and the user knows one minute after the installation why / what causes the trouble and removes the incompatible stuff again

Bad news for plugins that call noConflict().

Christoph

[Holger]

Bad news for plugins that call noConflict().

There're IMO no Plugins out there with no.Conflict() - beside yours and jerrys.
Both of you are able to release working versions without no.Conflict together with jQuery4CMSimple.
So - bad news for nothing

[cmb]

But one last word:

So I will test my plugin's code with noConflict(), but remove the call for the distribution.

I have 2-3 plugins that use lightbox + prototype, and right now I have no idea how to replace lightbox with jQuery.

http://planetozh.com/projects/lightbox-clones/, http://www.digitalia.be/software/slimbox2

[jerry]

I will remove noConflicts before release.
Protoype stuff will exist a while until I find out how to convert it to jQuery (and get time to do it) Right now I will just rewrite installation instructions.
jerry

[EDIT]
It seems that

Code: Select all

(function($) {
    /* some code that uses $ */ 
})(jQuery);

only works only when prototype.js is loaded after jQuery. Otherwise lightbox stops working.

This means that the sequence of frameworks loads means something and that jQuery must be loaded first. It will then be a matter of temper whether one uses jQuery or is wrapping the code in function($) {....})(jQuery).
jerry

[cmb]

Hello Jerry,

I said I wont speak again with regard to my noConflict() suggestion. But this is another matter, and even if I'm no JS expert, I'd like to give some comments.

Protoype stuff will exist a while until I find out how to convert it to jQuery

I don't really know which lightbox features you're using, but if you only use the standard feature (giving a rel="...") the solution might be as simple as including another jQuery based lightbox-clone, e.g. slimbox (that may not be the best choice, but it is the one I know, that works).

only works only when prototype.js is loaded after jQuery. Otherwise lightbox stops working.

The problem is IMHO the initialization code of lightbox, which might probably depend on $ as being the required prototype.js definition. Consider:
1. jQuery is included, so $ will be defined as by jQuery's definition
2. protype is included, so $ will be redefined as by prototype's definition
3. lightbox's initialization code will be executed , using $: everything is fine, because $ is the one defined by prototype!
Imagine (1) and (2) exchanged!

If this is so, there are AFAIK the following solutions:
1. ensure that prototype.js is loaded after jQuery, by calling your plugin e.g. zzzcarousel (IMHO a very ugly hack, but it might work)
2. Save prototype's $ definition in a variable directly after including prototype, and put that back to $, right when lightbox's init code will be called, and switch back to jQuery's $ definition directly after that (might be very tricky)
3. use jQuery's noC
4. don't use prototype.js in conjunction with CMSimple at all (probably best solution)

But that are only 2 cents of someone, who doesn't really know what happens behind the scenes.

Christoph

[cmb]

Hello Gert,

If the plugin developer have the choice between several JS librarys - he should choose jQuery.

, so wouldn't it be a good idea to state, that the only JS framework officially sanctioned by CMSimple is jQuery?

We don't want to have a mess like WordPress or Joomla.

Christoph