DZIRCMS provides autoloading for source files of classes/interfaces which are
delivered by a DZIRCMS package.
The main goal of autoloading is to reduce the list of needed includes which is usually
at the beginning of scripts. By implementing a autoloader, the PHP engine has the
possibility to load the file while trying to use a class/interface.
The DZIRCMS autoloader will be initialized during the application startup process. The autoloading solution in DZIRCMS uses the class map strategy. It uses a generated class map configuration file, which is available inside admin/data/config/ folder.
admin/data/config/config.autoloader.php
Each class type name is pointed to a file which contains the implementation of the
required class type. By trying to use a class type, the autoloader will load the
needed file if not done before.
Example:
Usually you have to ensure that a class file is already loaded by using include/require
statements or by using DZIRCMS's cInclude function:
cInclude('classes', 'class.article.php'); $oArt = new Article();
With a autoloader the manually loading is not required anymore.
$oArt = new Article();
At the moment all available classes/interfaces inside following directories of a DZIRCMS installation:
admin/classes/
NOTE:
The autoloader doesn't handle loading of files which don't belong to the DZIRCMS package.
This means, additional added files (e. g. user defined classes/libraries) aren't
automatically available for the autoloader. Read the section below, if you want to
provide autoloading of additional class type files.
Don't edit the class map configuration manually, the next update could overwrite your changes. The autoloading is extendable by adding a additional user defined class map file inside the "data/config" folder, which could contain further class map settings or could overwrite settings of main class map file.
admin/data/config/config.autoloader.local.php
This file will not be overwritten during a update.
The content of the user defined file should have the following structure:
<?php return array( '{classname_1}' => '{path_to_classfile_1}', '{classname_2}' => '{path_to_classfile_2}', '{classname_3}' => '{path_to_classfile_3}', );
Where {classname_X} is the name of the class/interface and {path_to_classfile_X} is the path (from DZIRCMS installation folder) to the file which contains the implementation of the class/interface.
Example:
Let's assume that DZIRCMS is installed in folder /var/www/ which contains a
additional library "myLib" (full path: /var/www/myLib/) with a class "myFoobarClass"
in file "class.myfoobarclass.php" (full path: /var/www/myLib/class.myfoobarclass.php).
Then the user defined class map file should contain a entry for this like:
<?php return array( ... 'myFoobarClass' => 'myLib/class.myfoobarclass.php', ... );
If you don't want to maintain the user defined class map configuration manually, then
you may let a copy of the command line script (which is adapted to your requirements)
admin/tools/create_autoloader_cfg.php
to do the job.
Do following steps to achieve this:
$context->pathsToParse = array( $context->contenidoInstallPath . '/my_path/', $context->contenidoInstallPath . '/my_other_path/', );
// class type finder options $context->options = array( // list of directories which are to exclude from parsing (case insensitive) 'excludeDirs' => array('.svn'), // list of files which are to exclude from parsing (case insensitive), also possible regex patterns like /^~*.\.php$/ 'excludeFiles' => array(), // list of file extensions to parse (case insensitive) 'extensionsToParse' => '.php', 'enableDebug' => false, );
By using the DZIRCMS autoloader it's possible to extend/overwrite DZIRCMS core classes (except classes inside conlib directory) without changing the core files.
Let's assume, you want to use your own Template class in Modules, but everything should
still be downwards compatible.
Do following steps to achieve this:
NOTE:
There is one main disadvantage by using this way of extending the DZIRCMS core.
Each time after an update of your DZIRCMS installation it's strongly recommend
to check your user defined implementations against changes in original DZIRCMS
core files and, if applicable, to adapt your files to those changes.