Move to jQuery

Foswiki's current javascript has been refactored and unit tested. But it will never be as up to date as other libraries. We should invest our development efforts smarter.

So now there is jQuery. Widely adopted, it has a large user community. And it incorporates many smart features like the selectors as we know from behaviour.js. Behaviour.js is useful, but jQuery is more mature, and is maintained.

Proposal

Refactored at 20 Mar 2009: updated with current technical state of Foswiki and developed best practices (thanks to SvenDowideit):

1. Add jQuery to the core distribution so that skins can make use of the interface possibilities
2. But do not assume jQuery will be available at all time with all skins
   • Since this feature request has been raised for the first time, we have created a workable solution to let Foswiki be Javascript library agnostic.
   • The Javascript lib is offered by skin path. For example, TwistyPlugin offers 3 different Javascript solutions, dependent on the Javascript lib that is installed.
   • This is made effective by writing SKIN = dojo,pattern
   • For PatternSkin to enable the jquery lib you would write SKIN = jquery,pattern

Implemented since first request

• Select which javascript toolkit I use using the skin path - so SKIN=jquery,pattern or SKIN=dojo,pattern etc. It means that people (like me) that create plugins like RestPlugin and JSPopupPlugin are able to automatically use the currently selected Javascript toolkit - very simple for the user.
  • A working example is TwistyPlugin
• Improve AddToHEAD to set the order, as Javascript and css depend on a certain order in which they are loaded by the browser (e.g. jquery.js before any jquery plugin).
  • The order of addToHEAD items can be set with parameter required; see addToHEAD doc
  • addToHEAD can now also be used in templates using %ADDTOHEAD{...}% - see ProcessAddToHeadAdds

Vote results

This proposal was voted for at the release meeting.

The arguments at the release meeting for making a decision on this proposal was that the rest of the discussion on this topic was about extending APIs and not addressing the actual topic: "jQuery or not jQuery" and that deciding FOR this proposal would not prevent implementing APIs and other fine ideas at a later time.

[23:44] <Lavr_> Sure:  1 yes (accept original proposal) 2 no (reject)  0 (don't know or don't care).
[23:44] <Lavr_> 0
[23:44] <ColasNahaboo> 1
[23:44] * OliverKrueger just read a quarter of the topics and neither has an oppinion yet.
[23:44] <PeterThoeny_> 1
[23:44] <uebera||> 1
[23:45] <ArthurClemens_> 1
[23:45] <OliverKrueger> 0

Accepted

-- KennethLavrsen - 14 Apr 2008

jQuery links

• http://jquery.com/
• jQuery for JavaScript programmers
• Nokia and Microsoft are adopting jQuery as part of their official application development platform

-- Contributors: ArthurClemens - 03 Dec 2007, 20 Mar 2009

Refactored discussion

and "(tm)wiki" renamed to "Foswiki"

Idea: Macro API / PluggableFoswikiJavascript

MichaelDaum suggested to let javascript implement functionalities through a macro API: the different Javascript tools offer a specific set of functionality which are able to be integrated into Foswiki using specific %TAG%s. These are then resolved by the underlying jquery/dojo/foobar plugin, adding the necessary headers and function calls.

We would need to agree on a tag interface that all of the real implementations have to adher to. For example:

• %BUTTON{...}%
• %TABPANE%, %TAB{...}%, %ENDTAB%, %ENDTABPANE%
• %TREEVIEW{...}%, %ENDTREEVIEW
• %TWISTY{...}% ...
• %TABLEPAGER{}%, %TABLESORTER{}%
• %AUTOCOMPLETE{}%
• %DRAGGABLE{}%
• %DROPAREA{}%
• %VALIDATEFORM{}%

Because the Javascript libraries are not 100% exchangable, they might not be able to cover all functionalities.

The advantage of this approach is that no extra level of javascript indirection is added between Foswiki and the actual Javascript toolkit.

Having Foswiki generate #ids will reduce mulitple DOM tree traversal (read: slowness).

So having Widgets can help with:

• a: generating the html stub by a Foswiki plugin
• b: generate #ids
• c: add only those necessary calls to the Javascript toolkit to the header pointing it to these #ids.

There is still a need for 'common' javascript functions, so that we don't find ourselves with a dozen subtly different implementations of (insert something here) that widget implementors all need.

StephaneLenclud mentioned that is was really easy to work with jQuery, and that adding a TAG layer would be:

• Extra effort to implement
• Foswiki specific - If I learn JQuery instead I can reuse that knowledge in other platform
• Limited power - It will only give access to a very limited subset of JQuery functionalities

jQuery is much too flexible that it would be reasonable to seal it behind Foswiki's plugin mechanisms. However, a standard set of variables does make a lot of sense, i.e. for standard users that don't know javascript, and who just want to have a tab interface for a couple of headlines. As Sven said, jquery can become hackerish.

Ongoing discussion

I have refactored the proposal and discussion to get me back on track.

-- ArthurClemens - 20 Mar 2009

I personally think, we just have to face the new age. The new age is a javascript supported browsing. The support of javascript gives you easy ways to improve the usability ESPICIALLY of systems like Foswiki, which have a lot of methods, functions and UI-Elements. I think, Foswiki is that far behind in terms of usability also because of the fact, that we never agreed to use a default JS-Framework. Instead we have several JS-raw implementations of things, which took a long time to let them work under all browsers, which took a long time to implement and they are long and ugly.This time wasting reinventing the wheels, so thats why we are so far behind. Alsoe NOBODY of us is a JS-Guru like the people developing such framework. Let us be an OS-Project which reuses the things other people create. Because thats exactly the reasons why OS-Software overpowers closed source software!

So please, dont make the Javascript-Framewok "plugable". Please let plugin-developers have an easy way to use Plugins for Javascript task,like tabs or whatever. And dont give them the hassle to test if its there and make fall-back-systems in case. This makes the whole thing just even more complicated.

That does not force you actually to USE the Javascript framework in your plugins. You simply can do thinks without it. But extensions might rely on it.

If we follow that way, we will have a lot of Foswiki-Specific Javascript-Framework extensions which are usefull for every developer to reuse.

In terms of the interface, i think it could be usefull to define a set of macros for general tasks, but as mentioned, we should not lock the Javascript-Framework behind it. It should be still useable the normal way.

I really really look forward to get a decision here. Even if i prefer JQuery, i would also be glad to see dojo or YUI as the default one - But please let use chose one.

-- EugenMayer - 20 Mar 2009

Any commitment - no matter which third party library it is - is better than none or even worse trying to be framework agnostic. This is asking for trouble of all sorts. Have a look at how fruitful Drupal's decision was to make extensive use of jquery. They use jquery, decision made.

The other point is: you can't just ship a bunch of js files with Foswiki and hope people will make any use of it. It needs some kind of convenience level. Fortunately, as we control the CMS underneath, we are in the convenient situation to offer such a thing using %tags%. Most tutorial material out there covers the quite different situation of people that only got access to their templates and thus need a way to enhance their blog in a somewhat unobstructive way using plain javascript. As noted above this has quite some performance disadvantages that we'd better avoid right away.

-- MichaelDaum - 21 Mar 2009

Agnostic does not mean that we are building for all Javascript libraries the same functionality. So jQuery is the preferred lib and enabled, that means that we will build jQuery solutions first, but leave open the possibility of creating the same solution with different frameworks if other people want to step in.

Imagine for example we want to have instant table sorting. Instead of hardcoding js sorting in TablePlugin::Core, we load the functionality through a template. We create the jQuery solution first, leaving the default as non-js enabled (current state). And we leave the possibility of other solutions for dojo or YUI if people want to contribute that.

Now to get very practical: which plugin or contrib that enables jQuery is best up to par?

-- ArthurClemens - 21 Mar 2009

I´m very happy to see Foswiki getting a decend javascript framework as a base.

Altough having flexibility is nice, I´m in strong favour of pushing only one framework for Foswiki. When we don´t have a consense on that our users will quickly have all available frameworks (YUI, jQuery, Dojo etc.) installed on their system, cause they installed plugins from different developers. This will obviously have a negative impact on performance and compatibilty.

Two years ago we had to choose internally for a framework. We decided to go with jquery, which actually was a very good decision when looking at the progess and adoption of jquery.

-- AndreUlrich - 22 Mar 2009

That's fantastic news. Very clever move!

-- StephaneLenclud - 22 Mar 2009

I am currently reworking JQueryPlugin and merging in the best of the other jQuery plugins. See Tasks.Item8144. The current version in SVN is tagged v1.99 and will be packaged and uploaded in v2.0. Please have a look at it, i.e. the authors of the other JQueryXXXPlugins.

-- MichaelDaum - 12 May 2009

Hi,

Just want to add my 2 cents here.

I used foswiki for a while (started on TWiki), and i just loved what JQuery has to offer... i really don't care what javascript libs are used, but being a complete ignorant about java and web apps in general makes me a with less capabilities to use the foswiki full potencial. What ever you decide, make sure there is an easy way (and well documented) to use it... I'll be anxious to see the new release...

thanks

-- RuiProcopio - 13 Jun 2009

JQueryPlugin v2.0 has been released. I think that's a good base for a jquery framework for Foswiki.

-- MichaelDaum - 24 Jun 2009

Cool move and I am happy to hear about it.

-- IngoKappler - 23 Jul 2009

I am re-factoring TinyMCEPlugin, which depends on JQueryPlugin. Just modest stuff for 1.1. Time for us to actually work on getting 1.1 jQuery-fied.

-- PaulHarvey - 26 Feb 2010