variables are bold
filenames are italicized
methods are bold underline
Portal Summary
The system works out of a Portal which provides user authentication, sessions etc. This information is provided to give you a general understanding of how the application works with the portal framework.
Each screen will submit back to the same script that sent it (index.cgi).
index.cgi, looks for variables app, state, and command from the cgi input stream.
It creates a new object of type app
Then it sends the other variables to app's run method.
The run method returns undef if there is a major problem or an HTMLObject containing the HTML output generated by the methods.
The portal then calls HTMLObject->display() which prints the output page to standard out.
NAMING CONVENTIONS: The app and state are Perl Modules so should start with a capital letter (i.e. Accounting). This system also capitalizes the beginning of new words in module name such as InvJournal. The command and all variable names should start with a lowercase letter and continue lowercase until reaching another word which should then be capitalized. (i.e. displayMenu) |
This is an idea of what happens in index.cgi. You will not need to worry about this when writing for the applications but this gives you a basic understanding of the portal.
$app = input{'app'};
eval("use Portal::$app;");
eval("use $appObject = Portal::$app->new(input=>$input, sessionObj => ....));
if (!$appObject->didErrorOccur())
$doc = $appObject->run(state =>$state, command => $command, input=>%input)
Modules in Accounting Package
After the application object is run it instantiates a state object and calls the run method. For example the Accounting.pm module would have something like this in its run method.
eval("\$stateObj = \$stateName->new(... );");
$doc = $stateObj->run(command => $command, input => %input);
In general as a programmer, you will not need to instantiate state
Objects, but here is the prototype for the StateObjects in the
accounting application:
StateObject
new(langObj, input, cookieObj, dbHandle, logObj, sessionObj, userObj,
companyObj, browserType, browserVersion, browserMaker)
On the other hand, when you submit to a page you must send certain variables for any state to work: app, state, command, ledger, ledgerCode
Once inside a state object's run command, some work will be done and a page will be generated based on input. The output will be placed in an HTMLObject that is returned at the end of the method. The recommended format for this method is to simply find out the command and call a sub routine to handle the work. This will allow for a much cleaner run method.
The accounting system will start with a menu page that lists the available ledgers. To open a ledger, the menu page submits, registers the window to be opened with the portal as {Ledger}{X} where X is the number of windows opened for that ledger. It would start with 1, 2, and so on. The layout of the window should be a frameset with the top frame named {Ledger}{X}Menu. The bottom frame will be titled {Ledger}{X}Data. This will most likely be done in the Ledger module.
These are standard forms that a page in the accounting application will use: mainForm, menuForm, optionsForm
<?>Instead of bombing out on an error, what if we set a variable to $message and set the command to $display. Then we have the display page show the message or popup a javascript window.
States
See also
Copyright (c) 2001 HLR
Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.1;
A copy of the license is available at
http://www.gnu.org/licenses/licenses.html#FDL.
Updated: $Id: Modules.html,v 1.1.1.1 2001/08/09 19:02:30 moreejt Exp $