more and more new plugins are using jQuery and every plugin used it's own way how to include the library to the page-head.
That caused a lot of problems and conflicts with other plugins in the past.

jQuery4CMSimple will provide a solution for all that problems.
It's thought as a "plugin for plugins" which handles the integration of jQuery, jQueryUI and other jQuery-based scripts.

As a developer
of a CMSimple-plugin with jQuery, you are advised to use jQuery4CMSimple to handle the integration of the libraries.
jQuery4CMSimple comes with a help file, containing ready to use code-examples.
Please have a look at the examples and give hints for your users about the dependency of your plugin and jQuery4CMSimple.

As a user
you only have to download, unzip and upload jQuery4CMSimple to your /plugins-folder on your webserver.
You can find a detailed description in the shipped help.htm.
There is no need to configure something somewhere.

jQuery4CMSimple will become part of the future CMSimple_XH - downloads > 1.4
In the meantime you can find more informations and the download-link atcmsimple-xh.com/wiki
(english translation follows ASAP).

But I'm loosing the overview. Posts about jQuery4CMSimple are scattered across several Threads. Is it possible to put these together?

One minor problem I might face: I didn't find jsTree in your documented jQuery plugin repository. What should I do with regard to include_jQueryPlugin(). Do I have to use another plugin? Should I choose 'jsTree' as first parameter? Should there be a place where users of such plugins can "register" those for CMSimple usage (maybe in the WIKI)?

And thanks again for the great idea to develop and publish such a plugin. You've made my day

cmb wrote:One thing is missing though IMHO: a convention about usage of noConflict()!

That's indeed something to discuss. 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.
But that's just my POV.

cmb wrote:One minor problem I might face: I didn't find jsTree in your documented jQuery plugin repository. What should I do with regard to include_jQueryPlugin(). Do I have to use another plugin? Should I choose 'jsTree' as first parameter? Should there be a place where users of such plugins can "register" those for CMSimple usage (maybe in the WIKI)?

Hehe, I've the same problem at the moment with my fancybox-plugin. My version is patched to deal with images made with a php script (imagename.php).
I don't know how to solve that...

Maybe you should give the name as written on the project page or in the top of the source-code.
I think there's not such a high risk for incompatibilities.
And if so, we have a new thread here at the board .

Holger wrote:
That's indeed something to discuss. 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.
But that's just my POV.

+ 1

Martin wrote:
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 - but as there are only a few jQuery-based plugins and Holger's integration is fresh and new, we could take the opportunity to establish this closure thing as "best practice"?

+ 1

I think you're both right. Another js lib is not necessary, but someone could integrate one in his plugin. So what to do?

I suggest to discuss this particular point (noConflict), so that future releases of jQuery4CMSimple could state the convention in it's documentation.

Holger wrote:
Hehe, I've the same problem at the moment with my fancybox-plugin. My version is patched to deal with images made with a php script (imagename.php).
I don't know how to solve that...

I don't quite understand the problem, but I have not used this plugin.

I've changed Pagemanager_XH to use jQuery4CMSimple. It worked like a charm. The API is simple; no more fiddling with $hjs And I like the addition of include_jQueryPlugin().

One question about the given download links for jQuery4CMSimple: I've linked directly to the jQuery4CMSimple page on cmsimple-xh.com. I don't think, that it's really useful for users to look for the plugin in the list. But: will this link be stable? Or is this the reason you've given the link to the plugin page in your documentation? I don't know exactly how many links to jQuery4CMSimple i have in the current version, I guess at least 7 (plugin info, error in $plugin_tx, documentation). I don't want to change them over and over again.

cmb wrote:The API is simple; no more fiddling with $hjs And I like the addition of include_jQueryPlugin().

That's nice to hear, because it was not simple to find a real easy solution. In my first attempts I've used just only one complex function like "register_plugin()" with a lot of parameters. But at the end I came back to that simple solution to make it easy to use for every developer.

cmb wrote:One question about the given download links for jQuery4CMSimple: I've linked directly to the jQuery4CMSimple page on cmsimple-xh.com. I don't think, that it's really useful for users to look for the plugin in the list. But: will this link be stable? Or is this the reason you've given the link to the plugin page in your documentation?

You're right. I've included the missing deep-link yesterday afternoon to the code examples in the help.htm. And the link to the page at the _XH-wiki will stay.
So it's fine to give the link to the download-page in your plugin.

BTW:
I've thought a bit more about the no.Conflict() stuff.
And in the meantime I think you're right. There must be a agreement / a code convention in the documentation of jQuery4CMSimple and on the wiki.

May I ask you to start a new thread at the Open Development Forum about that?
You have discussed in different threads a lot around that problem with Martin. It would be nice when you write down an extract of your experiences there.
Maybe this way, we can find contemporary a agreement about the usage of jQuerys no.Conflict().

Working fine with my stuff. No conflicts with prototype.js and lightbox, nor jquery plugins I use
Using jQuery instead of $ solves right now all conflicts with lightbox. It seems that jQuery.noConflict will be only necessary with some jQuery plugins that don't proerly wrap their code.
I will make some more tests during this week.
jerry

Do you mean you've integrated jQuery4CMSimple to be used by your plugins, or do you mean,that your plugins do work with other plugins using jQuery4CMSimple? I guess the former, but I'm not sure. In this case, I'm happy you're using jQuery4CMSimple, because that could make the life of all jQuery using plugin authors easier. I hope, all those authors will update their plugins ASAP.

jerry wrote:
Using jQuery instead of $ solves right now all conflicts with lightbox. It seems that jQuery.noConflict will be only necessary with some jQuery plugins that don't proerly wrap their code.

Yes I rewrited Newsbox Rotator to jquery4Cmsimple and I will release it in few days. I did ask for a standard way to include jQuery, I've got it and I use it .

I have read some of your code and I can see that you use Martins sugestion with noConflict (it was new for me too). For my part it seems that I can just replace $ with jQuery to avoid conflicts with lightbox and anything else I know. But I'm still testing. It seems that jsTree doesn't wrap its code properly, I guess that's why you need to use noConflict replacement. But Pagemanager and Newsbox Rotator can now be installed in the same cms.
jerry