legend

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.

  1. Each screen will submit back to the same script that sent it (index.cgi).

  2. index.cgi, looks for variables app, state, and command from the cgi input stream.

  3. It creates a new object of type app

  4. Then it sends the other variables to app's run method.

  5. The run method returns undef if there is a major problem or an HTMLObject containing the HTML output generated by the methods.

  6. 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

Accounts

SubAccounts

Departments

Config

Ledger

Register

Reports

Investment Journal

Portfolio

StockPrices

Capital Gains and Losses

Payroll

Assets and Depreciation



See also

Objects      Database Objects


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 $