Вникаем в нюансы программирования Request Tracker

Привет, читатель!
В данной теме я расскажу о принципах построения системы request tracker с точки зрения программирования, т.к. это достаточно хорошая система учета заявок и может быть использована на крупном предприятии в качестве helpdesk-системы.

Кому интересно — добро пожаловать под кат.

Вступление или немного о системе:

Система написана на perl, работает с любым(я проверял на 2-х) http-сервером. Обширен набор БД, с которыми может работать система. Достаточно быстра, генерация страниц происходит «на лету» и тормозов с обновлением контента не наблюдается. Были детально рассмотрены две последние стабильные ветки — 3.8 и 4.11.
Основные отличия между ветками коснулись интерфейса, при том же наборе конструкторов в коде с небольшими изменениями. Однако, в 3.8 используется фреймворк prototype и почти не используется ajax, в то время как в 4.11 используется jquery(что на мой взгляд гораздо удобнее) и используются ajax-конструкции.

Углубимся в код:

Система использует пакет Mason, который позволяет встраивать perl-код в документ:

use HTML::Mason

Почитать про структуры Mason можно здесь ^[1].
Так же, система использует серьезный режим кеширования, который может вызвать отторжение при программировании под RT на первых этапах, т.к. каждый раз при изменении кода следует «убивать» сессии RT, очищать кэш и перезапускать http-сервер. Эти действия, конечно, можно объединить в скрипт, но есть другой вариант — следует установить в файле конфига RT_Config.pm опцию:

Set($DevelMode,"1")

Эта опция отключает кэширование обьектов, что позволяет писать под RT с использованием ajax.

Детальная структура каталогов RT представляет собой группы каталогов, названные по категориям объектов. Например:
Для объекта «Ticket»(заявка) структура будет такой:

• /Ticket
• /Ticket/Attachment
• /Ticket/Elements
• /Ticket/Graphs
• /Ticket/Create.html
• ...

В каждом каталоге элемента имеется папка Elements, в которой содержатся конструкторы для данного типа элемента.
Приведу пример:

<& /Elements/Header, Title => $title, onload => "function() { ... } " &>

Эта конструкция вызывает заголовочный файл как класс, с указанием параметров. Мне это показалось сходным с jquery. Достаточно удобно, да?
При программировании нужно учитывать тот факт, что можно создать свой элемент и подключать его как класс. Или воспользоваться готовыми решениями при проектировании.

О локализации

Система поддерживает большинство языков. Найти языковой пакет не составит труда, он находится здесь:
{%RTHOME%}/lib/RT/I18N/*.po — для RT 3.8
{%RTHOME%}/share/po/*.po — для RT 4.
Структура файла локализации крайне проста и вписать свои переменные или изменить существующие труда не составит. Для подключения переменной используется операнд:

<% loc("param") %>

Ajax

Следует отметить один подводный камень при построении ajax-конструкций: вследствие использования Mason, интерпретатор не принимает основную функцию jquery — $. Поэтому в RT 4 следует использовать:

jQuery.ajax(...)

а в RT 3.8(т.к. используется prototype.js):

new Ajax.Request(....)

Кратко о работе с Mysql

В системе имеется интерфейс для доступа к БД. В моем случае это база mysql. Чтобы подключиться к текущей базе RT, необходимо определить переменные:

my $dbname = RT->Config->Get('DatabaseName'); # имя БД
my $dbhost = RT->Config->Get('DatabaseRtHost'); # хост 
my $dbuser = RT->Config->Get('DatabaseUser'); # имя пользователя для текущей БД
my $dbpass = RT->Config->Get('DatabasePassword'); # пароль в открытом виде

Получив переменные, мы уже можем(даже не используя интерфейс RT для доступа к БД) подключиться к mysql. Например, с помощью

use DBI::mysql;
my $dbh = DBI->connect(...)

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

Здесь рассмотрены лишь малые знания(нюансы) в области программирования RT, полученные в результате выполнения некоторого проекта по доработке выше описанной системы. Если данная тема интересна, то в будущем напишу более углубленные знания, касающиеся API RT.
Спасибо за внимание.

Автор: mister_j

Источник ^[2]