The Opendelight provides three core objects to be used in application development - $DB, $APP and $USER. These objects are automatically instantiated and are available in the application. The $DB object is responsible for database access and data manipulation. The second object $APP is the instance of application when an HTTP request is made and carries all related data. The $USER object carries data of the user accessing the system (uses Row Gateway Data Pattern), and is only instantiated if the controller is private. The interaction of $APP and $USER objects are based on RBAC (Role-based Access Control) scheme as described in Overview of Opendelight Architecture.

The speciality of the objects is that one does not need to instantiate these three objects. These objects are automatically available within the application main scope. You can also make them available within any Model class by accepting them as global within class constructor; i.e.,
global $DB, $APP, $USER;
$this->DB = $DB;
$this->APP = $APP;
$this->USER = $USER;

Database Object ($DB)

The Database object requires the values of the Opendelight Array, $_DELIGHT, (usually stored in the file during the installation of the framework) to get instantiated. The $DB object is basically PDO (PHP Database Object), and can be used in application instance to perform database operations. As PDO supports many major databases including MySQL, PGSQL, and Oracle, etc., developers can choose databases freely based on situations and requirements. It is required that all database queries must be executed through prepared statements - well, that gives immunity against SQL injection.

Application Object ($APP)

The application object requires application event ID (that is available on $_REQUEST) to get instantiated. It depends on other critical parameters like ID (event ID that determines the application instance) or IDN (This is the name of application instance (availed from $_REQUEST superglobal and can be used instead of ID). The later is usually employed for beautifying URL, and also for tagging event's ID for readability during development. After instantiation of $APP object, the following values becomes available to the application instance:

IDThis is the instance ID of Application or Event ID
EVENTVERIFIERThis is an expression that will be validated before the application instance is executed.
FORMRULESThis is an array which store sanitization information for individual form fields values received through $_REQUEST. If there is no such requirement for any application instance, this array remains empty.
VIEWPARTSThis is an array that stores a list of view parts (refer to sub-section on View Parts in this section) in the order of display.
PAGEVARSThis is an array that stores strings alongside keys:
TITLE: Title of Page
H1: Heading of Page
H2: Subheading
BASEURLBase URL of the application
URLFull URL of the application instance
CONFIGStores user-defined configuration settings
SYS['NAME']: Name of Application
['AUTHOR']: Description of Application including license information, links, etc.
['DESCRIPTION']: The author of the application
TABLEPREFIXThis stores the table prefix of user-defined tables

User Object ($USER)

The User object requires $APP an object to get instantiated, but you do not need to be worried - it is taken care of automatically. On the other hand, $USER is instantiated only if $APP->ISPUBLIC returns false (managed within the controller - you do not need to manage this code, rather will mark the controller as private on the Opendelight IDE). The $USER object depends on critical parameters like User's ID and VERIFIER (the verifier is a unique string generated at the time of user creation and differentiates users having common session pool in the server for different applications - again you do not need to be worried about this as these things are taken care of automatically), but avails it from $_SESSION superglobal. After instantiation of $USER the object, the following values becomes available to the application instance:

IDThis is the ID of user accessing the application. There will be no ID if the controller is public; i.e., $APP->ISPUBLIC returns true
USERNAMEThis is username
EMAILThis is user email
FULLNAMEThis is the full name of the user
LASTLOGINThis is DateTime information of the user when he/she signed last

The Opendelight Array

These are system variables and MUST NOT be used during application development. The table below lists all elements of the Opendelight Array:

Variable NameLocationDescription
$_DELIGHT['DSN']System Config fileDatabase Source Name
$_DELIGHT['DBUSER']System Config fileDatabase Username
$_DELIGHT['DBPASSWORD']System Config fileDatabase Password
$_DELIGHT['TABLEPREFIX']System Config fileDatabase Table Prefix
$_DELIGHT['CTRID']Controller FileController ID

When the Opendelight is installed, the first four elements are defined. These values are stored in the file and are the same for all instances of the application. The fifth element is defined during runtime when a controller receives an HTTP request.

Apart from the Opendelight Array, a few elements from $_REQUEST/ $_SESSION Super Globals should not be used as they store system runtime data. These are listed in the table below:

Variable NameLocationDescription
$_SESSION['USERID']Session Super GlobalUser ID
$_SESSION['IDVERIFIER']Session Super GlobalUser ID Verifier - An additional verifier is a string generated randomly and is unique to the user across the server. This is used to distinguish the user from others if more than one application with the same user object data share the same session pool in the server or cloud.
$_SESSION['REQUESTURL']Session Super GlobalThis is the URL user requests which gets stored in the session and are used to come back to the same location after signing in.
$_REQUEST['ID']Request Super GlobalThis stores the event ID of the application instance.
$_REQUEST['IDN']Request Super GlobalThis is the name of the application instance. This is used for beautifying URL, and also for tagging event's ID for readability during development.

The Opendelight Libraries

The Opendelight Libraries are classes developed or distributed as part of the Opendelight to facilitate additional objects to develop your application. These classes are available in /lib the directory, and are autoloaded when instantiated (i.e., you do not need to include these class files in the application when you want to instantiate them). The names of these classes usually start with Delight_.

The following are the classes currently available as the Opendelight Libraries:

Delight_GridThis class is used to perform backend operations for data grid display.
Delight_FormThis class is used for processing form for sanitizing form input data and for performing additional validations. This uses other opensource scripts, but have been packaged inside the distribution. Sanitize is a part of this class.
Delight_CaptchaThis class is used to display and verify CAPTCHA in public forms.
Delight_SignThis class is used for performing signing in, signing out, and retrieving password in the application.