Postadmin 2

Ранее я уже писал о собственном веб-интерфейсе Postadmin для управления почтовым сервером. Писал я его с двоякой целью. Во-первых, я хотел приобрести опыт написания веб-приложений, а во-вторых, расширить возможности почтовой системы - добавить аутентификацию пользователей, сложные схемы пересылок, квоты для почтовых ящиков, ограничения на отправку.

При написании веб-интерфейса я пошёл по пути наименьшего сопротивления. Поскольку на тот момент я обладал довольно слабым знанием SQL, то решил не разрабатывать структуру таблиц с нуля, а воспользоваться имеющейся структурой, при необходимости добавляя новые поля и таблицы. Также, поскольку у меня в прошлом уже был опыт написания приложений на PHP, я решил воспользоваться именно им. Эти два решения позволяли мне увеличить шансы на успешное достижение целей.

По ходу реализации у меня сложилось некое подобие фреймворка - диспетчер обработки запросов, библиотечка для доступа к БД, зародыш шаблонизатора, несколько виджетов. Сейчас я смотрю на эту программу с изрядной долей самоиронии. Нет, она прекрасно работает, сам я легко в ней ориентируюсь, однако всё это похоже на детские каракули.

В начале года я стал осваивать Perl и начал пользоваться первым попавшимся шаблонизатором HTML::Template. Для работы с базами данных я освоил практически не имеющий альтернатив модуль DBI, что, впрочем, не так уж и плохо - DBI весьма хорош. Из трёх найденных мной веб-фреймворков, Catalyst, Mojolicious и Dancer, я решил остановиться на Dancer, как на наиболее простом из всех них. Это, конечно, не самый лучший набор инструментов, но для многих задач он вполне достаточен, а по сравнению с моим самописным недофреймворком на PHP он бесспорно лучше.

Итак, для закрепления навыков владения перечисленными инструментами (Perl, HTML::Template, DBI, Dancer), я решил портировать на них Postadmin. Функционал по синхронизации информации с порталом SharePoint я решил не воспроизводить, т.к. в настоящее время мне негде его отлаживать. Впрочем, почтового сервера у меня теперь тоже нет, поэтому в программе могут присутствовать некоторые скрытые недоработки. Если (вдруг!) кто-то решит воспользоваться этой программой и обнаружит недоработку, я готов её исправить.

Снимков экрана не привожу, так как шаблоны страниц фактически те же самые. Получившийся архив можно взять здесь. Вместе с самим веб-интерфейсом в архиве есть примеры настройки базы данных, веб-сервера, postfix и dovecot и небольшая инструкция.

Шаблоны HTML::Template в Perl-фреймворке Dancer

Захотелось немного изучить веб-фреймворк Dancer, т.к. писать с использованием модуля CGI и его компании хоть и можно, но не удобно. Особенно раздражает неудобство в использовании cookie, а ещё больше - неудобство установки или удаления cookie в редиректе. Хотя, конечно, этим всё не ограничивается.

Ставим фреймворк:

# apt-get install libdancer-perl

Создаём каркас будущего приложения под названием test:

$ dancer -a test

Теперь можно перейти в каталог test/bin и запустить оттуда приложение app.pl:

$ cd test/bin
$ ./app.pl

Запустится только что созданное приложение test, которое будет ожидать подключений на TCP-порту 3000. Можно открыть в браузере ссылку http://localhost:3000 и увидеть тестовую страницу:

Как вы уже догадались по заголовку заметки, необычное в этом снимке экрана только одно - строчка "Template engine: html_template".

По умолчанию в Dancer'е используется некий "простой" шаблонизатор simple. В качестве альтернативы предлагается использовать template_toolkit, я же хочу воспользоваться html_template, который по сегодняшним временам кому-то может показаться довольно "дубовым".

К сожалению, в репозитории Debian этого модуля нет. Поэтому поставим сначала пакет dh-make-perl:

# apt-get install dh-make-perl

Теперь с его помощью поставим нужный нам Perl-модуль Dancer::Template::HtmlTemplate, соглашаясь при первом запуске на все умолчальные настройки:

# dh-make-perl --install --cpan Dancer::Template::HtmlTemplate

Теперь укажем Dancer'у, что мы хотим использовать этот шаблонизатор в нашем приложении. Для этого закомментируем в файле настроек config.yml в каталоге проекта строчку шаблонизатора simple и добавим строчку с шаблонизатором html_template:

#template: "simple"
template: "html_template"

Теперь самое время отредактировать шаблоны в соответствии с правилами выбранного нами шаблонизатора - заменим все строчки типа "<% var %>" на строчки типа "<TMPL_VAR NAME="var">". Шаблоны находятся в каталоге views проекта и имена их файлов оканчиваются расширением ".tt".

Теперь можно снова запустить наше тестовое веб-приложение и увидеть ту самую страницу, снимок которой я привёл выше.

Если заглянуть в исходный текст модуля, то можно увидеть, что опции HTML::Template, используемые при загрузке шаблона, можно настроить всё в том же файле настройки config.yml:

my $ht = HTML::Template->new(
  filename => $template,
  die_on_bad_params => 0, # Required, as we pass through other params too
  %{$self->config}
);

Я использую настройки utf8 и loop_context_vars. Их я и пропишу в файл config.yml:

engines:
  html_template:
    utf8:              1
    loop_context_vars: 1

Теперь создадим в каталоге views шаблон страницы hello, поместив в файл hello.tt следующий текст:

<h3 align="center">
<TMPL_VAR NAME="name">
</h3>

И откроем файл test.pm в каталоге lib, допишем в него обработчик страницы hello:

get '/hello/:name' => sub {
  template 'hello', { name => param('name') };
};

Теперь перейдём по ссылке "http://localhost:3000/hello/превед" и увидим следующее:

Страница создана на основе макета, лежащего в файле views/layouts/main.tt и созданного нами шаблона view/hello.tt. Если захочется поменять что-то в макете - можно отредактировать его, можно создать новый макет и положить его рядом. Выбрать используемый макет можно прямо в обработчике. В документации приведены два примера.

Отключение макета на определённой странице:

get '/' => sub {
  template 'index', {}, { layout => undef };
};

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

get '/user' => sub {
  template 'user', {}, { layout => 'user' };
};

На этом пока всё.

Perl и UTF-8

Оставим в стороне теорию, о ней достаточно написано из без меня, например, здесь Пара слов про UTF-8 и здесь UTF Perl Practice, или как использовать UTF-8 в перле. После прочтения теории я занялся практикой и сделал для себя следующие практические заготовки.

Включаем флаг UTF-8 для всех строк в программе:

use utf8;

Выставляем флажок UTF-8 для всех строк, прочитанных или записанных в текстовые файлы, включая стандартные потоки ввода-вывода:

use open qw(:std :utf8);

Странным образом предыдущие настройки включают блочную буферизацию стандартных потоков вывода. Отключаем её:

select(STDERR);
$| = 1;
select(STDOUT);
$| = 1;

Выставляем флажок UTF-8 для всех строк, полученных в переменных CGI:

use CGI qw(:cgi -utf8);

Выставляем флажок UTF-8 для файла, с помощью которого грузится шаблон HTML::Template и все подшаблоны. К сожалению, не нашёл в документации модуля способа однократно задать использование этой настройки глобально.

my $template = HTML::Template->new(filename => "/var/www/index.tmpl",
                                   utf8 => 1,
                                   die_on_bad_params => 0,
                                   global_vars => 1);

Чтобы модуль DBI выставлял флаг UTF-8 для всех строк, прочитанных из БД MySQL или переданных ей, выставляем настройку в дескрипторе соединения.

$dbh->{mysql_enable_utf8} = 1;

Аналогично для PostgreSQL:

$dbh->{pg_enable_utf8} = 1;

Нужно отметить, что эти настройки для DBI не указывает кодировку клиента, а только лишь дают инструкцию модулю выставлять флажок UTF-8 у строк.

На этом, вроде, всё.