Item8655: JQueryPlugin fails if no ZonePlugin is present

Which could prevent us shipping JQueryPlugin with Foswiki 1.1

So trunk is broken for any dev trying to use TinyMCEPlugin out of the box, despite JQueryPlugin itself being brought in as a core dependency.

Added a configure checker to help us keep this moving and make things less confusing.

If %ADDTOZONE% can't be merged to core this month, and therefore JQueryPlugin be shipped as a default plugin, we will have to abandon any plans for a JQuery implementation of TinyMCEPlugin

-- PaulHarvey - 03 Mar 2010

Sad truth is that in order to ImprovePageLoadTime, ALL of the javascript integration has to be cleaned up, independent of any %ADDTOZONE%. Page load time currently is substantially influenced by sub-optimal javascripting all over the place, starting at JavascriptFiles. See also FormaliseJavascriptLibraries .

-- MichaelDaum - 03 Mar 2010

Why not fix JQueryPlugin so it does not have a dependency of ZonePlugin?

It was never a condition when we decided to say yes to JQueryPlugin.

In my view ZonePlugin is too yoing to go into 1.1. And in fact in a 2.0 context this zone feature should really go to core and not be a plugin.

-- KennethLavrsen - 03 Mar 2010

Added some commentary at ImprovePageLoadTime

-- PaulHarvey - 03 Mar 2010

Kenneth the zone feature is proposed to be added to the core for quite some time now. ZonePlugin is not proposed to be added as a plugin.

See the docu.

-- MichaelDaum - 03 Mar 2010

quite some time is since February 4th.

Currently trunk is broken. We cannot use the Wysiwyg editor at all at the moment because it now depends on JQueryPlugin which again depends on a plugin that is not supposed to be in core.

Please remove this dependency so we can get trunk back in working order. It blocks the rest of us fully test on trunk.

There is no good reason why JQueryPlugin TODAY should not work.

Same with TinyMCE. Why is it suddenly broken so I cannot edit pages anymore on trunk?

Please fix JQuery ASAP so it does not depend on ZonePlugin. JQuery is full of Foswiki::Func::addToZone. This is plain wrong in the current situation.

We need some stability now.

-- KennethLavrsen - 03 Mar 2010

I originally wrote this thing (attached) that monkey patches Foswiki::Func::addToZone() with a fake version that's just a wrapper to addToHEAD(). But figured there's enough of that happening already.

JQueryPlugin has a few modules that use addToZone(). Converted those to call JQueryPlugin's own wrapper method, instead of monkey patching Func.

-- PaulHarvey - 04 Mar 2010

I hope the checkin I made is only temporary until we decide on ImprovePageLoadTime. I did try to avoid it by creating checkers, but as KennethLavrsen, SvenDowideit, and at least two or three other devs on IRC still had problems (probably due to ./pseudo-install doing symlinks incorrectly) I feel I ran out of options.

It is regrettable that I had to "deface" the JQueryPlugin like this, it should only be temporary.

In hindsight it seems I added JQueryPlugin to core with very unfortunate timing.

• JQueryPlugin.FakeAddToZone.diff: Adds a fake addToZone() :-/

-- PaulHarvey - 04 Mar 2010

The faked addToZone patch is aweful. Don't check it in, please.

Let's proceed thike this: If we don't see an agreement on ImprovePageLoadTime, JQueryPlugin will revert all calls from addToZone back to the core's addToHead again for obvious reasons. As long as css, js and meta are added to the page in separate calls, ZonePlugin will be able to optimize it, when installed. Furthermore, there is disagreement on the name "zone". Depending on the decision made there (good alternative is area to make it sound more CMS-ish), the ZonePlugin will be renamed, all non-core plugin dependencies will be changed accordingly. ZonePlugin (or AreaPlugin) will then have to check if the Func does not yet provide the improved API (as many other plugins do) and only then monkey patch it.

-- MichaelDaum - 05 Mar 2010

See Item8696.

-- MichaelDaum - 25 Mar 2010