Dynamically parsed HTML pages
This is a mechanism which allows for extending WebRSH's functionality without having to write any additional Perl code or to modify any of WebRSH itself. WebRSH's online help pages are implemented using this mechanism. It can also be used for many other things, such as for creating menus with various command links.
The two main things to note about dynamically parsed HTML pages are:
The general format for the special dynamically replaced strings is
<!$VariableName!> where $VariableName can be any of
$BGColor, $BodyParam, $TableColor, $FTableParam, $TableParam, $ScriptUrl,
$SendFilesUrl, $counter, $id, $lpwd, $plpwd.
The definitions and proper usage of these variables can be determined
by looking at the main WebRSH script and at some of the existing pages
in the 'htm' directory.
Once an HTML page is located in WebRSH's 'htm' directory, it can be
invoked as a dynamically parsed HTML page by using the command:
rshgethtm <htmname>
(which can be issued by an appropriate link) where <htmname>
is the name of the file. WebRSH's Main Form is being appended to such
pages, such that they appear as an integrated part of it.
WebRSH ships with one specific dynamically parsed HTML page that can
be invoked from WebRSH's Main Menu and provides a natural place for
adding command links. This is the 'more.htm' page in the 'htm' directory,
which is invoked through the 'MORE' link in the Main Menu.
Plugins
WebRSH plugins are simply CGI Perl programs that can be integrated with WebRSH. In principle, CGI programs written in other languages can also be used, but they would need to be "wrapped" in a Perl script. The plugin mechanism can be used to:
There are three main things to note about plugins:
So, if plugins are simply CGI programs, what is the point in making them plugins in the first place?
There are a number of advantages to doing that. In particular:
Let us now describe the plugin architecture in more detail. There are actually two kinds of plugins. The first kind are 'library plugins' which must reside in WebRSH's 'lib' directory (the 'lib' subdirectory of the 'Main Program Directory'). The second kind are 'user plugins' which must reside in WebRSH's 'Plugin Directory'. The 'Plugin Directory' may be set to be the same as the 'lib' directory, but it can also be moved elsewhere if desired or needed. The idea of having these two kinds is that scripts whose main purpose is to be integrated parts of WebRSH should be implemented as 'library plugins', while self contained programs that are merely being used as plugins should be implemented as 'user plugins'. Also, with a system-wide install of WebRSH, system-wide plugins can be implemented as 'library plugins' and be located in a central 'lib' directory, while users can have private plugins in their own private plugin directories. Both kinds of plugins are simply CGI programs and have essentially the same requirements and capabilities. There are some mild differences in how the two kinds are being invoked (see below), and in the way they get executed by WebRSH. More specifically, 'user plugins' are being launched from the directories in which they reside (since many CGI programs expect that), and also the Perl $0 variable (which holds the identity of the currently executed script) is being set for them such that they know who they are if they need to. 'Library plugins', on the other hand, get launched from whatever directory the server is launching the main WebRSH script from, and have their $0 variable set to this WebRSH script. The main implications of all this are:
Once a plugin is located in its appropriate directory, it can be invoked by specifying an appropriate URL. This URL should be formatted as follows:
<webrsh_url>/rshplugin/<id><webrsh_working_directory>%3A%3A/<plugin_name><plugin_parameters>
Where:
<webrsh_url> is the basic URL for the webrsh script (e.g., http://hostname.domain/webrsh/webrsh.pl)
<id> is the WebRSH 'id' parameter. It should be set to the proper value of $id when the link is being generated dynamically, but otherwise it can be simply 0 (or 1, or any other digit)
<webrsh_working_directory> is the WebRSH working directory encoded in an appropriate way. It must start with a '/'. It should be set to the value of $plpwd when the link is being generated dynamically. Otherwise, it can be set manually. On UNIX platforms this parameter must point to a valid directory. On Win32 platforms the preceding slash is being removed, such that setting it to '/' means a null directory name--which is effectively the same as the WebRSH home directory. Other than that, however, whatever follows the first '/' must point to a valid directory.
<plugin_name> is the name of the file containing the plugin script (without any directory information).
<plugin_parameters> are any parameters (such as a query string) that would normally be specified to follow the script filename if it where called as an independent CGI script. This parameter is optional, namely, it can be nothing.
<webrsh_url>/rshplugin/<id><webrsh_working_directory>%3A%3A/LibPI<plugin_name><plugin_parameters>
The parameters here are the same as for 'user plugins'. The only difference is the appending of the string 'LibPI' before <plugin_name>. This is how WebRSH recognizes the plugin as a 'library plugin'. One consequence of this mechanism is that 'user plugins' should never have names that start with the string 'LibPI'.
The natural way of invoking plugins is through appropriate dynamically generated links which can be placed in dynamically parsed HTML pages. The 'more.htm' page in WebRSH's 'htm' directory (which is invoked by the 'MORE' link in WebRSH's Main Menu) is a natural place. Alternatively, it is also possible to modify the main WebRSH script and/or the menu file of the 'Frames Interface' and add such dynamically generated links there (links to plugins in the menu file of the 'Frames Interface' should be generated with the 'MakePluginLink(*)' JavaScript function).