Feature Proposal: Support loading REST and tag handlers from contribs

Motivation

registerRESTHandler and registerTagHandler can currently only be called from plugins, unless a contrib is booted through some other means. This is silly; contribs are equal citizens, and need to be able to call these methods even when a plugin hasn't included them. Consider MailerContrib for an example of this; I want to add a REST handler for mailnotify, as described in Tasks.Item8316.

Description and Documentation

Add the following code to Foswiki::new, right at the end, just before the return:
    # Load and initialise required modules
    if (defined( $Foswiki::cfg{Require} )) {
        foreach my $module (values %{$Foswiki::cfg{Require}}) {
            require $module;
            my $fn = $module.'::onNewSession';
            if (defined( &$fn )) {
                no strict 'refs';
                &$fn( $this );
                use strict 'refs';
            }
        }
    }
This will require the module (at some performance impact) and anything it uses, and call the onNewSession method on it for every new session creation. This method gives the contrib an opportunity to register handlers.

Similar code in finish, at the start of the function:
    if (defined( $Foswiki::cfg{Require} )) {
        foreach my $module (values %{$Foswiki::cfg{Require}}) {
            my $fn = $module.'::onFinishSession';
            if (defined( &$fn )) {
                no strict 'refs';
                &$fn( $this );
                use strict 'refs';
            }
        }
    }
Neither onNewSession nor onFinishSession are required to be defined in a Contrib.

Finally, configure needs a checker for $Foswiki::cfg{Require}

Questions:
  1. do we need control over the order in which onNewSession and onFinishSession are called?
  2. Arguably default tag handlers should be registered the same way, as per Meredith's tags work.
-- Contributors: CrawfordCurrie - 07 Dec 2009

Discussion

The best motivation to convert a contrib into a plugin is because it needs to participate on the callback mechanism for plugins. So question is: how about making MailerContrib a MailerPlugin and thats it?

-- MichaelDaum - 08 Dec 2009

If it is not practical to convert the contrib to a plugin, why not create a MailerPlugin that provides the callbacks needed by MailerContrib?

-- MichaelTempest - 08 Dec 2009

I originally created the 'Contrib' concept to overcome the overhead of plugin initialisation; which is of course a lot less now that we no longer use auto-discovery. There is another approach that might be worth exploring; and that would be to support plugin modules that don't observe the naming standard for plugins. For example, if {Plugins}{MailerContrib}{Module} were set to Foswiki::Contrib::MailerContrib::Plugin then I should be able to treat it as a plugin; might require some relaxing of the rules on plugin topics, but that would be no great loss.

l8r - somewhat to my suprise, that worked beautifully. See HowToAddRESTAndMacroHandlersToContribs for details.

Rejected my own proposal.

-- CrawfordCurrie - 08 Dec 2009
Topic revision: r4 - 08 Dec 2009, CrawfordCurrie
The copyright of the content on this website is held by the contributing authors, except where stated elsewhere. See Copyright Statement. Creative Commons License    Legal Imprint    Privacy Policy