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:Registration of Unit Classes

From In-Portal Developers Guide

Jump to: navigation, search
Unit Configs Unit Configs
Статьи в этой категории

To use a particular class in In-Portal, it must first be registered. Class registration is a process, the result of which is that In-Portal learns about:

  • The name of the class;
  • The location of the file where the class is written;
  • The pseudo that's going to be used when referring to an object of the class.
Image:Infobox Icon.gif pseudo - a keyword that can be used from any place in In-Portal application to get an object of a class that's registered under the pseudo.


Contents

Getting an Object

The kApplication::recallObject can be used to get an object, for example:

$price =& $this->Application->recallObject('price');
/* @var $price kDBItem */

In order for auto-complete to work in Zend Studio, it's necessary to put a specially formatted comment after getting an object. The general form of this kind of comment is:

/* @var $variable_name ClassName */

Registering a Class

In a configuration file there are a number of options with similar formats for the purpose of registering classes in K4:

Option Name Corresponding pseudo
ItemClass (array) <prefix>
ListClass (array) <prefix>_List
EventHandlerClass (array) <prefix>_EventHandler
TagProcessorClass (array) <prefix>_TagProcessor
RegisterClasses (array) Задаётся в ручную в ключе "pseudo".

In the above table, "<prefix>" is the value of the Prefix option in a configuration file. The value of each above option (except RegisterClasses) is an array of the following format:

Array (
	'class' => 'ClassName',
	'file' => 'FileName',
	'build_event' => 'BuildEventName',
	'require_classes' => 'RequiredClassName'
)

All of the keys in this array, except require_classes, are required. However, the value of some of the keys can be empty.

Name Description
class (string) Name of the class being registered (new of new class or system class).
file (string) Name of the file where the class is written (one file per class); if empty, then it's assumed that a system class is being used.
build_event (string) Event from event handlers, used for initializing copies of the class being registered (i.e. an object). In other words, this is a class constructor, which is located in the event handler.
require_classes (mixed) Name of the class(es), which must be loaded before using this class. If one class is indicated, then the value of the key can be a String. If several classes are indicated, then the value of the key must be an Array.
Image:Tipbox Icon.gif The value of all keys (except build_event) of this array must follow naming conventions rules]].

Substituting Classes

There are cases when one or more classes used in the system must be substituted. To do this, the RegisterClasses key is used. When registering or substituting a class, in the RegisterClasses key it's required to indicate an additional pseudo key. In this case it must be set because it's not known automatically (like in all of the previously described situations).

'RegisterClasses' => Array (
	Array ('pseudo' => 'u_TagProcessor', 'class' => 'EUserTagProcessor', 'file' => 'e_user_tp.php'), // substitute a user tag processor
	Array ('pseudo' => 'PermissionsHelper', 'class' => 'ЕPermissionsHelper', 'file' => 'e_permission_helper.php'), // substitute a class helper
)
  • When substituting a class the "pseudo" must be set with which the original (i.e. the one being substituted) class was registered.
  • Registration of the substitute class must be done after registration of the original class. This requirement is automatically fulfilled if class substitution is done in the "custom/units/sections/sections_config.php" file.

Standard Classes

The following standard classes are available:

  • kDBItem - class for working with one database record;
  • kDBList - class for displaying the contents of a database table (filters, per-page, etc.);
  • kDBEventHandler - class for processing standard events from lists and edit forms;
  • kDBTagProcessor - class for processing standard tags used for displaying information;
  • kEventHandler - root class for all event handlers (use only with the goal of reducing memory usage);

The value of the file key should be empty for standard classes.

Translated from: revision 1070