In-Portal Developers Guide

This is a wiki-based Developers Guide for In-Portal Open Source CMS. The purpose of this guide is to provide advanced users, web developers and programmers with documentation on how to expand, customize and improve the functionality and the code the In-Portal software. Please consider contributing to our documentation writing effort.

K4:Application Process Flow

From In-Portal Developers Guide

Jump to: navigation, search

Структура приложения Структура приложения
Статьи в этой категории

Contents

kApplication - main class of the system

The object of kApplication class is created one of the first ones and among all key properties contains links to other important classes such as Session, TemplateParser, kFactory, kHTTPQuery, kEventManager and others. At the same time, almost all other objects in the system have a back-link to the main Application object. This allows flexible interaction between different parts of the system.

Example below, demonstrates that this kind of approach (when main application object links to other key objects) allows to call any type of event from any part of the system.

$event = new kEvent('custom-sections:OnAddListingLog');
$event->setEventParam('mode', LISTING_MODE_EXTERNAL);
$this->Application->HandleEvent($event);

Method kApplication::HandleEvent passes the actual event processing to an object of kEventManager class. A link to that object is stored inside of application $this->Application->EventManager property.

At the same time, for event processing from kEventManager::HandleEvent method system makes calls to other methods of the main Application class. For example, in order to get the object of Event Handler for specific event we are using the following:

$event_handler =& $this->Application->recallObject($event->Prefix.'_EventHandler');
/* @var $event_handler kEventHandler */
$event_handler->processEvent($event);

As you can see, we are calling for kApplication::recallObject method, which gets a link to required Event Handler by making call to another base object, link to which is accessible in the Factory property of Application object.

$result =& $this->Factory->getObject($name, $pseudo_class, $event_params);

In case if Event Handler object hasn't been created yet, then object of kFactory will create it for the first time while making another call to a base Application object to get and process Build Event which is triggered any time system creates a new Event instance:

$event =& $this->Application->EventManager->getBuildEvent($pseudo_class);
if($event)
{
	$event->Init($prefix,$special);
	foreach($event_params as $param_name=>$param_value)
	{
		$event->setEventParam($param_name,$param_value);
	}
	$this->Application->HandleEvent($event);
}


Main Phases in Application Process Flow

These are Initialization, Processing and Completion phases. Below is example from standard index.php file:

$application =& kApplication::Instance(); - getting a link to Application object
$application->Init(); - initialization phase
$application->Run(); - processing phase
$application->Done(); - completion phase

Initialization

The key point of initialization in In-Portal is to get the most out your application by building strong and complete infrastructure. This done by initializing and creating all necessary objects, properly defining relations between them, and then processing all incoming data from HTTP requests (GET/POST/COOKIES and others) and finally properly apply all this data on the Web-server, database and application itself.

Connecting to Database and Creating Connection object

Specifically for this task there is a code inside of kApplication::Init() method:

$this->Conn = new kDBConnection(SQL_TYPE, Array(&$this, 'handleSQLError') );  // new object
$this->Conn->debugMode = $this->isDebugMode();
$this->Conn->Connect(SQL_SERVER, SQL_USER, SQL_PASS, SQL_DB); // connecting to the database

Connection to the database is handled through the object of kDBConnection class. Once created, a link to a database object is placed inside of Conn property of the main Application object. In it's turn, this new object of kDBConnection class is getting a link-back to the main Application object in it's construction method using the following code:

$this->Application =& kApplication::Instance();


Note that a link to database object can also be stored as a separate Conn property in other objects that tightly connected to database and can make often database calls. Good examples are objects of kDBBase class and his inheritors kDBItem and kDBList classes. This done for better performance:

function kDBBase()
{
	parent::kBase();
	$this->Conn =& $this->Application->GetADODBConnection();
}

Thus, once initialization is complete, the access to the database can be done virtually from any place:

$all_tables = $this->Conn->Query('SHOW TABLES');


Creation of Factory Object and Registering New Classes

There is a code inside of kApplication::Init() method:

$this->Factory = new kFactory();

Factory object is one of the key objects in the entire Application. It's designated to keep track of other objects that already been created and return a link to it in case if one is requested by the Application. It's obvious that object of kFactory class is created before any other standard objects.

In-Portal wides uses Late Initialization approach. Objects are created only when they are needed or required by someone. kFactory

class provides a functionality when Late Initialization is done automatically as long as proper classes are registered and will be used in creation of its objects. Class Registration is quick and low resource operation which simply saves in properties (array format) of Factory object the following data:
  • pseudo-name of class:
  • path on the file-system to actual class
  • list of other classes that must be defined before this class

Right after creation of Factory object system will continue registering other base classes critical to the application. This is done through the following method:

$this->RegisterDefaultClasses();

Note that any of these Default classes registered via kFactory class can be replaced at later point of initialization based on your application needs.

Translated from (revision 1033)