Home » Support » Help Articles » Batoi OSF Objects, Arrays and Libraries

Batoi OSF Objects, Arrays and Libraries

Back to Help Articles Home


The OSF 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 is based on RBAC (Role based Access Control) scheme as described in Overview of Batoi OSF 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 OSF Array, $_DELIGHT, (usually stored in the file sys.inc.phpcreated 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., developer can choose database freely based on situation 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 other critical parameters like ID (event ID that determines the application instance) or IDN (This is name of application instance (availed from $_REQUEST super global 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:

AttributesDescription
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 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 application
TABLEPREFIXThis stores the table prefix of user-defined tables

User Object ($USER)

The User object requires $APP 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 OSF 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 super global. After instantiation of $USER object, the following values becomes available to the application instance:

AttributesDescription
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 fullname of user
LASTLOGINThis is datetime information of user when he/she signed last

The OSF Array

These are system variables and MUST NOT be used during the application development. The table below lists all elements of the OSF 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 OSF is installed, the first four elements are defined. These values are stored in the file sys.inc.php, and are the same for all instances of the application. The fifth element is defined during runtime when a controller receives HTTP request.

Apart from the the OSF 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 - additional verifyer is a string generated randomly and is unique to the user across the server. This is used to distinguish user from others if more than one application with 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 session and is used to come back to the same location after signing in.
$_REQUEST['ID']Request Super GlobalThis stores the event ID of application instance.
$_REQUEST['IDN']Request Super GlobalThis is name of application instance. This is used for beautifying URL, and also for tagging event's ID for readability during development.

The OSF Libraries

The OSF Libraries are classes developed or distributed as the part of the OSF to facilitate additional objects to develop your application. These classes are available in /lib 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 OSF Libraries:

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


Updated on Aug 20, 2016

The techReview is an online magazine by Batoi and publishes articles on current trends in technologies across different industry verticals and areas of research. The objective of the online magazine to provide an insight into cutting-edge technologies in their evolution from labs to market.

Visit techReview


English - IN (USD)
New Users? Signup.     Existing Users? Login.