Refactoring FatCgiScripts into a module

One of the things O'Wiki has done recently that I like a lot is a refactoring of most of the scripts in bin/ into subroutines in a module TWiki::UI. Thus, each script simply does a bit of setup and then calls 'TWiki::UI::$0'. This can be done initially with very little effort, maybe even automated. But once it's done it allows easier consolidation of common functionality between the scripts, because they'll be side-by-side in the same file and the similarities will be more obvious.

If everything in bin/ could be replaced this way, then it becomes practical to replace all the stubs with a 'master' script that uses PATH_INFO to determine the action. If you placed it in the main TWiki directory the URL's wouldn't even change, although that might introduce some Apache configuration issues. This opens the way to a more dynamic handling of TWiki 'actions', perhaps going so far as to allow (a new class of?) plugins to register action handlers for new actions, once everything in bin/ is run out of a single stub. Of course, there are issues with these plugins, because many of the things one would want to do in a plugin 'action' may need further effort in FuncDotPm, or maybe even a new type of interface to the core code more suited to an action handler than a rendering plugin. However, before I start with serious additions to the plugin API I want to take a hard look at RefactorPluginAPI.

-- WalterMundt - 09 Feb 2004

An important aspect of this refactoring is the separation of the CGI query from the functional elements of the different scripts. If every TWiki::UI function does it's own my $query = new CGI (as in Owiki:FeatureDescriptionAntelope), then the individual functions are not callable from elsewhere - not good!

-- CrawfordCurrie - 09 Feb 2004

Walter - spot on. You may want to look at the precomp script. (Currently pretty hacky, but it's designed as an apache 404 error handler, and integrated in with the installer. The idea behind the precomp script, not finished, is to allow it to redirect the user from (say) http://owiki.org/SiteIndex to http://owiki.org/SiteIndex.html automagically. It's not a huge leap of the imagination to change it so that it has ?action=edit and so on which change the environment to look like a twiki/bin/edit script. As you noted this allows plugins to gain access to higher level functionality.)

Crawford - I agree, but before I go there I need to make it possible for the global state to be stacked/put aside - so I'm factoring out globals etc. One particular change I really want to do is to allow myself to do an all lastdiffs view. I've implemented a first pass at this, so I know it's a nice feature, but the overhead of network includes back to itself is very heavy (due to the inability to "stack" requests).

-- MS - 09 Feb 2004

mmm, it'd also have the result that we would have 2 master scripts (one authenticated by the web server, the other anonymous), and we can then dynamically allow different functions to be authenticated or not.

-- SvenDowideit - 10 Feb 2004

Yup. The precomp/etc scripts are just a simplified version of an earlier script that did just that. (Called auth - I posted it on TWiki.org a while back when chatting to TedPavlic)

-- MS - 10 Feb 2004

Is that related to ImproveViewAuthentication?

-- SamHasler - 24 Feb 2004