В Limb3 выработавшейся практикой стало использование констант для настройки определенных системных параметров. Большинство констант начинаются с ключевого слова LIMB_, однако есть константы шаблонизатора WACT, которые имеют префикс WACT_

Почему же именно константы, а, скажем, не глобальные переменные или настроечные файлы? Давайте по-порядку:

• Глобальные переменные более «хрупки» нежели константы. Хотя и легкость изменения является соблазнительным аргументом в пользу глобальных переменных, скажем, во время тестирования, на нашей практике было довольно много случаев, когда это и было существенным минусом(например, они могут быть запросто случайно изменены плохо работающим кодом).
• Константы, на наш взгляд, проще использовать в коде чем глобальные переменные, сравните: echo LIMB_VAR_DIR; и echo $_GLOBALS['LIMB_VAR_DIR']; (хотя глобальным переменным надо отдать должное по поводу удобства использования внутри строки, например, «{$_GLOBALS['LIMB_VAR_DIR']}»)
• Мы не отказываемся от настроечных файлов, однако считаем, что низкоуровневые параметры намного проще конфигурировать с помощью констант. Константы доступны сразу средствами языка, тогда как настроечные файлы тянут за собой определенные зависимости(например, класс, который осуществляет парсинг настроечных файлов). Сравните:

Используем константу:

require_once(LIMB_VAR_DIR . '/foo.php');

Используем некую подсистему для получения параметров:

require_once(get_conf_value('LIMB_VAR_DIR', 'common.ini') . '/foo.php');//вводим зависимость от get_conf_value и наличия файла common.ini

Если присмотреться ко всем объявлениями констант в Limb3, то можно увидеть, что почти каждая константа объявляется совместно с оператором подавления ошибки «@». Сделано это для того, чтобы константы можно было объявлять где-то выше с иными значениями.

Например, где-то в модуле foo.php объявляется константа LIMB_FOO:

foo.php

<?php
..
@define('LIMB_FOO', 'hey');
...
?>

Предположим, что базовый скрипт инициализации setup.php приложения подключает foo.php, тогда в setup.php можно как бы «переобъявить» константу LIMB_FOO, т.е, по сути, объявить ее раньше:

setup.php

<?php
..
@define('LIMB_FOO', 'wow');
..
require_once('foo.php');
?>

Возникает резонный вопрос, почему не использовать конструкцию if(!defined('LIMB_FOO')){define('LIMB_FOO', …)}, ведь оператор @ является довольно медленным? Ну во-первых, объявлений констант не так много, чтобы это существенно повлияло на общее время работы приложения. А во-вторых, на наш взгляд, использовать @ намного проще чем длинную if(..) конструкцию.

Документацию на не перечисленные здесь константы стоит искать в описании конкретного пакета.

• LIMB_VAR_DIR(string) - указывает на некоторую доступную на запись директорию. Обычно в проекте эта директория имеет название var и находится в корневой директории проекта. Все временные данные, кеши, логи, т.е все то, что может быть безболезненно удалено хранится в этой директории. Эта директория должна всегда находиться в списке svn:ignore системы версионного контроля. Пример использования:

@define('LIMB_VAR_DIR', dirname(__FILE__) . '/var');

• LIMB_CACHE_DB_META_IN_FILE(boolean) - объявляет, стоит ли кешировать метаданные структуры базы данных. По умолчанию имеет значение false. Используется в пакете DBAL. Строить метаданные структуры БД при каждом запросе - довольно обременительная задача, поэтому имеет смысл эти данные кешировать(они хранятся в директории LIMB_VAR_DIR в файле db_info.xxx.cache). Отменять кеширование имеет смысл только во время разработки, но не на продукционных серверах. Пример использования:

@define('LIMB_CACHE_DB_META_IN_FILE', true);//включаем кеширование

• LIMB_SESSION_USE_DB_DRIVER(boolean) - объявляет, стоит ли использовать в качестве хранения данных сессии базу данных. По умолчанию имеет значение false. Используется в пакете WEB_APP. На данный момент в Limb3 сессию можно хранить либо в БД либо в файловой системе стандартными средствами PHP. Пример использования:

@define('LIMB_SESSION_USE_DB_DRIVER', true);//используем БД

• LIMB_INI_INCLUDE_PATH(string) - список путей через «;» указывающих директории относительно include_path, в которых стоит производить поиск *.ini настроечных файлов. По умолчанию 'settings;limb/*/settings'. Используется в пакете CONFIG. Обычно полезно переопределять эту константу в тестах. Пример использования:

@define('LIMB_INI_INCLUDE_PATH', 'tests/settings;settings');

• LIMB_CONF_INCLUDE_PATH(string)- список путей через «;» указывающих директории относительно include_path, в которых стоит производить поиск *.conf.php настроечных файлов. По умолчанию 'settings;limb/*/settings'. Используется в пакете CONFIG. Обычно полезно переопределять эту константу в тестах. Пример использования:

@define('LIMB_CONF_INCLUDE_PATH', 'tests/settings;settings');

• LIMB_TEMPLATES_INCLUDE_PATH(string) - список путей через «;» указывающих директории относительно include_path, в которых стоит производить поиск шаблонов. По умолчанию 'template;limb/*/template'. Используется в пакете WEB_APP.

• LIMB_CONTROLLERS_INCLUDE_PATH(string) - список путей через «;» указывающих директории относительно include_path, в которых стоит производить поиск контроллеров. По умолчанию 'src/controller;limb/*/src/controller'. Используется в пакете WEB_APP.

• LIMB_WACT_TAGS_INCLUDE_PATH(string) - список путей через «;» указывающих директории относительно include_path, в которых стоит производить поиск WACT тегов. По умолчанию 'src/template/tags;limb/*/src/template/tags;limb/wact/src/tags'. Используется в пакете WEB_APP.