MegaTWikiServiceRegistrationMethods

At the moment, MegaTWiki implements a rudimentary service registration which "notifies" its service dispatch method which services are available for use at compile time.

At the top of the MegaTWiki.pm module, I have placed some code which executes before any code is compiled:

BEGIN {
  use vars qw( %validHandlers );
  %validHandlers=();
  sub registerHandler {
    my $handler=shift;
    my %info=@_;
    %{$validHandlers{$handler}}=%info;
  }
}

Before each subroutine which implements a service in the MegaTWiki.pm module, I have placed some code which resembles this:

BEGIN {
  registerHandler("accesscontrol",
     description => "Access Control",
     menuitems => {
     "Edit Folder Access" => "mode=WEB",
     "Edit Topic Access" => "mode=TOPIC"
   }
   );
}

The effect of this code is to fill the %validHandlers hash via the registerHandler subroutine with information about the methods by which each service may be accessed via an HTTP POST to the mega CGI script, and to register the service handler with the handleRequest method. The information is also used to fill out the menu on the left-hand side of the MegaTWiki administration screens.

Services are requested of MegaTWiki from the mega script in the following manner:

    my $query = new CGI;
    my $thePathInfo = $query->path_info();
    my $theRemoteUser = $query->remote_user();
    my $theTopic = $query->param( 'topic' );
    my $theUrl = $query->url;
    my( $topic, $webName, $scriptUrlPath, $userName, $dataDir ) =
        &TWiki::initialize( $thePathInfo, $theRemoteUser, $theTopic, $theUrl, $query );

    my $megatwiki = TWiki::Plugins::MegaTWikiPlugin::MegaTWiki->new(
                        -query => $query,
                        -topic => $topic,
                        -web => $webName,
                        -user => $userName,
                        -datadir => $dataDir
                      );

    return $megatwiki->handleRequest();

Actually, that's pretty much the whole of the mega script.

MegaTWiki is initialized with the CGI query, to access any CGI arguments specific to it's services, the topic, web name, user name, and the data directory, after which the handleRequest method is called.

The handleRequest method (shown below) then executes as follows:

1. retrieve the request CGI argument from the query object,
2. check to see if the request is valid
3. execute the request's handler (if valid)
4. execute the default handler (if request is invalid)

MegaTWiki.pm's handleRequest method:

sub handleRequest {
  my $self=shift;
  my $query = $self->{'args'}{'-query'};
  my $request = $query->param('request');
  $self->{'request'} = $request;
  if($request && defined($validHandlers{$request})) {
    my $tmp="\$self->${request}Handler()";
    $tmp =~ /(.*)/;
    $tmp = $1;
    eval "$tmp";
  } else {
    $self->defaultHandler();
  }
}

As I said, this is fairly rudimentary; I was primarily using the handleRequest registration method as a way to achieve a single point of contact with the MegaTWiki module for obtaining services. The handleRequest subroutine itself might be useful towards TWikiOO, but I'd much rather see a different method for filling out the %validRequest hash for self-registration or discovery of TWikiService objects and the services they might provide.

It would probably be good to start a discussion centered around TWikiServiceDiscoveryAndRegistration.

-- PeterNixon - 12 Jul 2002

Call me thick, or lazy, but could you possibly draw me a diagram?

Thanks, M.

-- MartinCleaver - 12 Jul 2002

Unfortunately, not at the moment, because my browser at work doesn't seem to like the TWikiDrawPlugin applet much (funny... I work at Sun; this should "just work" ). Plus, I'm not very good at diagramming a hack... But I will do an outline of events until I can get to my home machine (Mandrake Linux, works great!):

Picture in your mind a steaming pile of TWiki code, just waiting to be compiled!

1. The mega script is read in by the perl interpreter.
2. TWiki code is read in by the perl interpreter (because of the use TWiki; statement).
3. The mega script begins execution.
   1. mega instantiates a CGI $query object and extracts what it needs to initialize TWiki.
   2. mega calls the TWiki::initialize subroutine, and TWiki begins to initialize all the plugins.
      1. Plugin manager reads in the MegaTWikiPlugin.pm and the MegaTWiki.pm modules. As the MegaTWiki.pm file is parsed, the code wrapped in BEGIN blocks is compiled and executed before any of the other code is executed.
      2. The code in the first BEGIN block defines a hash called %validHandlers, and a subroutine called registerHandler, which is used later to fill out the hash.
      3. The next BEGIN block is encountered, which contains a call to the registerHandler subroutine, passing in a hash of information that will be used to fill in the %validHandlers hash.
      4. This continues until the MegaTWiki.pm file is compiled and all services have been registered.
   3. mega instantiates a MegaTWiki ($megatwiki) object and initializes it with the required CGI parameters and query information.
   4. mega calls MegaTWiki's handleRequest subroutine to process the request with which the $megatwiki object was initialized, in which it:
      1. retrieves the request CGI argument from the query object,
      2. checks to see if the request is valid
      3. executes the request's handler subroutine (if the request is defined in the %validHandlers hash)
      4. executes the default handler (if request is not defined in the %validHandlers hash), which simply brings up the default mega screen.
   5. The mega script exits, hopefully after making someone's day .

-- PeterNixon - 12 Jul 2002

This is good!

There is one thing I'm keen to change: split up the responsibilities of Presentation as html and invocation of functionality (that retrieves WikiML). Having them combined means MegaTWiki qualifies by my definition as a FatCgiScript.

My intent is to progress the MegaCgiScript into first a solution for PluginBinNameClashes and then a way to get to CommonFrontEndCgiScript.

-- MartinCleaver - 14 Jul 2002

Yes, I'd like to split up the WikiML generation from the HTML rendering of WikiML if possible, but they are fairly intertwined at the moment ... It'd be nicer if the handler simply returned some WikiML or fully rendered HTML for the MegaCgiScript to print to STDIO. (Subject moved to BackendsShouldReturnWikiML by MartinCleaver)

This brings up another topic: PluginVariableNameClashes.

-- PeterNixon - 14 Jul 2002