Item8655: JQueryPlugin fails if no ZonePlugin is present
Priority: Urgent
Current State: Closed
Released In: 1.1.0
Target Release: minor
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.
--
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