Item12403: Add condition checking for version numbers of plugins

JQuery is a shifting target, with important plugins coming and going and core functions deprecated on a regular basis. That means that any code that depends on JQuery has to be updated as and when the core changes. That in turn means There will be versions of jquery - and versions of other plugins - that no longer work with your updated code. Currently there is no check for this.

The idea is to add a 'conditions' field to plugins constructors that will not interfere with older versions of JQueryPluginn but will support the checking of version number dependencies.

See UsingJQueryWithFoswiki#TestingConditions for details of the implementation.

-- CrawfordCurrie - 22 Feb 2013

See feedback at http://irclogs.foswiki.org/bin/irclogger_log/foswiki?date=2013-02-22,Fri&sel=202#l198

i.e.

[17:34] <MichaelDaum> the other problem that I have is: this is all in the code path of rendering a page: being evaluated again and again
[17:34] <MichaelDaum> coming to the same result
[17:34] <MichaelDaum> thats not good
[17:34] <MichaelDaum> it really is a configure matter: once you worked out all conditions, it is all done, once and forever
[17:37] <MichaelDaum> the benefit is comparably low, targeting only the one situation out of a million where things then end up in a die().
[17:38] <gac410> I know it still needs work,  but the new configure has an in-depth dependency checker on the Audit page that will check all plugin dependencies as well as core deps.
[17:39] <MichaelDaum> and thats best suited to catch any jquery dependencies as well

-- MichaelDaum - 22 Feb 2013

To support checking in configure requires a number of things:

1. A version number for each available plugin that is accessible to configure
2. A statement of the dependencies

Currently the version number of JQuery plugins is hard-coded into the constructor for the plugin. This means that to access the version number, something has to instantiate the plugin. Since the plugin code is heavily dependent on the JQueryPlugin/Foswiki infrastructure, this cannot currently be done without a Foswiki environment, which is not available within configure. Further, because plugins are instantiated by registerPlugin rather than by the Foswiki scrape-a-directory mechanism, there is no way to locate plugins without a Foswiki instance. Our existing mechanism for stating dependencies between extensions (DEPENDENCIES) uses the perl-standard $VERSION identifier in the plugin code, which it is able to scrape from the source code because it is always known where those modules are in the directory tree. JQueryPlugins are sometimes packaged using the BuildContrib, which solves the dependencies problem at a stroke. But unfortunately most are not.

The upshot of all this is that there is a significant amount of work required in the JQueryPlugin to leverage the existing configure infrastructure. What I have coded is, I believe, the best that can be done without investing in this work, and has an extremely low overhead for plugins that do not have dependecies. "The benefit is comparably low" - sorry, but this is total bollocks. I wasted a signficant amount of time trying to work out WTF was going on with code that was assuming an old version of livequery, something I could have trapped immediately had there been a dependency mechanism. The rate of change in JQuery, and our lack of control over most of the plugins (which come from outside the Foswiki project) means that such a dependency mechanism is increasingly important. Perhaps not to you, Michael, but to everyone else.

-- CrawfordCurrie - 25 Feb 2013

I see. I agree in parts on what you've said.

Btw. this is the change that removed the feature you where using in ActionTrackerPlugin's javascript code: https://github.com/hazzik/livequery/commit/20efab24d8a93d653db8f7a35ec1294a5d68d0ae

I am seriously in doubt that your code solves the problem you had. As I said on IRC: you are mixing up two separate things:

1. configuration management vs
2. plugin initialization

Configuration management is done "offline" that is out of the rendering loop happening on every click on every page. Plugin initialization does happen for each page being rendered, and has to be as fast as can ever be. This means checking plugin dependencies during page rendering again and again is plain wrong. It still remains wrong even when the proper way of managing dependencies in the configure domain is impossible right now. It still stays wrong no matter how tiny the overhead is at the moment given that not a single plugin is using the feature you are trying to implement. The consequence is not to implement something even though even you yourself know that it is not really the right thing to do. It means that we need to find a way to make it possible for configure to read $VERSION information properly.

Unfortunately things changing in jquery land are not as stable as we would like to have it and like we try to maintain Foswiki code here. Yet we still are relying on these 3rd party modules. And the same stability issue arises with any other 3rd party code, i.e. modules in cpan and even perl itself. I can't help you with that other than staying informed on what's going on and more testing.

Let's improve by discussing this on a proper feature request first before adding features that we can't remove anymore later on. For now, I will revert your code.

-- MichaelDaum - 27 Feb 2013

OK, fair enough. I agree about configuration versus runtime - it's why I wrote configure, after all. The implementation I did was all I could do in a reasonable amount of effort.

Note that if the only dependency is on a version of jQuery, then a Checker can be used - see the checker in ActionTrackerPlugin for an example. However for the reasons given above you cannot check dependencies on other jQuery plugin, so even with the Checker ActionTrackerPlugin has an unchecked dependency on livequery.

You can easily use configure checkers by simply repackaging the jQuery plugins as BuildContrib modules. That would not alter any code, or the way they are used; simply the way they are packaged. We could easily add a jQueryPlugin type to the list (Plugins, Skins, Contribs, JQuery) - it would simply be a type of Contrib. The version number could be centralised through the following code in the jquery plugin:

use Foswiki::Contrib::LiveQueryJQuery ();
.....
version => $Foswiki::Contrib::LiveQueryJQuery::VERSION,
.....

-- CrawfordCurrie - 28 Feb 2013

No actions for a long time.

-- MichaelDaum - 22 Nov 2016

Commenting is disabled while not logged in