Item1337: Bring clarity: JQueryPlugin or JQueryLibPlugin?

2 plugins that do the same? Please, which one is out?

Then there is also:

• JQueryCompatibilityModePlugin
• JQueryDevPlugin
• JQueryTwistyPlugin

This is too difficult for me, let alone for our users!

Also, I would expect JQueryLibPlugin to be called JQueryLibContrib, as it has no core code and makes the js code available. Except for the color field picker, but is that the only reason the plugin needs to be enabled? I suspect even that perl code can just be distributed with a contrib, just as JSCalendarContrib does.

-- ArthurClemens - 20 Mar 2009

Iam actively developing JQueryCompatibilityModePlugin. In general it does the same as JQueryPlugin ( is it missing in your list? ). The most important difference is, that in my extension JQuery is running in compat mode, so bound to $j, so it can coexist to other framework that are binding $. In addition, i am encapsulating all script that way, that they work with $ also. So in general all scripts i write in addition to JQueryCompatibilityModePlugin work with $ and $j, so also with JQueryPlugin.

The second difference is the way i am including things and that i provide a dialogAPI in addition as a configureable "auto inlcude"..i also handle some JQuery Theme related stuff and introduce the same Javascript globals as Michael does, but i think they are more complete. In addition there is a non complete Foswiki.Func api which should be the JS-Counterpart to the perl-one ( mostly trying to work on the Global Foswiki var or making rest calls to the real perl-api ).

Also JQueryPlugin has some Foswiki-Specific plugins.

JQueryTwistyPlugin is as far as i know some old rest before it got integrated into the TwistyPlugin, but thats to decide by Michael.

I am open to merging JQueryPlugin and JQueryCompatPlugin when:

• Compat mode is used
• All scripts are encapsualted by the code below, so the inner scripts can work with $j or $ or $youanme or whatever

;(function($j) { . . })(jQuery);

• A more lucid directory structure is used then its currently in JQueryPlugin

All in one, its highly recommended to merge them together, as they simply have the same goal.

-- EugenMayer - 21 Mar 2009

i am not in favor of merging any of these libraries; instead, should there not be a "bottom-most" JQueryContrib which is "merely" the packaging of the sources from jQuery without any library additions from us? those should be created as additional addon packages, imho.

-- WillNorris - 23 Mar 2009

I think it would be less developer-focused (i.e., a good thing) to merge them. I'm surprised that I agree with Eugen's recommendation, since that's about all I understood in his posting

As a system administrator, I prefer merging because it's one less thing to maintain, and it removes any concerns about having version A of one and Version B of the other.

Will, could you expand on your reasoning?

-- SeanMorgan - 23 Mar 2009

I would also like to see jQuery running in compat mode. The fact it cant play nice with other frameworks is one of the things I hate about it.

I also think it would be better packaged as a contrib, rather than a plugin. That way we will know that all it does is contain the library and nothing else. Also a contrib could contain its own addToHead function that adds the js/css files to the header only once and in the correct order. All plugins can then use that function if they need to add a particular library file.

Either way, I think Foswiki only needs one jQuery package.

-- AndrewJones - 23 Mar 2009

I dont think JQuery should be a contrib. In both JQuery plugins Foswiki-specific plugins are included. there are clearly separated in the JQueryCompatibiltyModePlugin by a directory. They are not included by default but they can be used. And they come in handy really really often. There are a lot of things you can use JQuery for in Foswiki, but when you start to implement the interface to foswiki from new every single time, you waste time. In addition, thats what i did not see in any other plugin yet is: JS + i8n. I have implemented such a thing for the dialog system, but its not in the JQCMP yet. Its an interface to MAKETEXT of our perl-lib. When Foswiki boots up, it creates a JS-hash including all translated strings you told him to do so, then you can access them by Foswiki.MAKETEXT['Hello']. This is just an example of something usefull you will run into anyway. Its best practise to define such an interface before.

Other examples is the JS-Func API. Why is is that implemented in JQuery? Because its much easier to do async-calls to rest handlers if needed.

I think we should ship JQuery as a single part in the plugin, but also include such helpers, which are clearly separated though ( and can be disbaled ).

-- EugenMayer - 24 Mar 2009

This seems stalled. How can we make this more actionable?

If I don't get an advice I will make a decision myself.

-- ArthurClemens - 12 Apr 2009

JQueryDevPlugin can be scraped most of its functionality was merged into JQueryPlugin ages ago. Please don't change JQueryLibPlugin without telling me first I'm using it to develop SoftSkin which is now running in my production environment. I posted there some bad excuses as of why I decided to create JQueryLibPlugin rather than build up on the existing JQueryPlugin. It was mostly motivated by my schedule, workload and time constraint to be honest.

-- StephaneLenclud - 28 Apr 2009

I will port JQueryPlugin to foswiki now and have a look at the other jquery plugins to see what can be merged.

-- MichaelDaum - 28 Apr 2009

A bit off-topic, but would you consider including a JQuery auto-complete library? That would obsolete AutoCompletePlugin and its requisite (but optionally installed) YahooUserInterfaceContrib, and perhaps fix a problem with using auto-complete in WebTopBar (described in my unresolved support issue at t.o.).

-- SeanMorgan - 28 Apr 2009

jquery.autocomplete is part of JQueryPlugin for some time now.

-- MichaelDaum - 28 Apr 2009

There is also a Extensions/Archived.AutoCompletionLibPlugin plugin for JQuery autocompletition. It should wor with both JQuery-Plugins, until you include the JS-Libs it additionally depends on.

Michael while you port the plugin, are there any plans to integrate some things of the JQueryCompatibilityModePlugin into it? Do you plan to make a switch for the compatibility mode plugin in you ones so that mine gets obsolete and we can merge it down to one?

-- EugenMayer - 29 Apr 2009

Eugen, yes sure.

For now I try to rework JQSCRIPT and JQSTYLE replacing it with a JQREQUIRE that will add everything that is needed to HEAD automatically. jQuery plugins will get a perl pendant that encapsulates dependencies and %TAG implementations as needed.

-- MichaelDaum - 29 Apr 2009

The AutoCompletePlugin could be made to work with either jQuery or YUI using the templates system in the same way that the TwistyPlugin does, if anyone has the motivation to do so (see MoveToJQuery for background on this, although its been refactored now). It would certainly be a good idea if it was not dependent on a specific library. The main reason I wrote the AutoCompletePlugin was to allow auto complete fields in forms, so it would not be obsoleted if it was just switched to jQuery.

I created Item8145 for making AutoCompletePlugin Javascript library agnostic.

-- AndrewJones - 29 Apr 2009

Formfield type color has been ported from JQueryLibPlugin to JQueryPlugin. IMHO, this can be closed now.

-- MichaelDaum - 23 Jun 2009