Куда разархивировать? Для простоты предлагается создать отдельный каталог для дополнительных библиотек. Пусть каталог htdocs – это корневой каталог размещения документов на веб-сервере. Создадим на одном уровне с ним каталог lib, и разархивируем в него наши движки, каждый – в отдельный каталог. Получится вот такая структура директорий:

В каталоге XTemplate будут файлы PHP-библиотеки, демонстрационные примеры и т. п. В каталоге HTML может находиться один-единственный perl-модуль – Template.pm

Собственно, на этом все необходимые манипуляции по установке будут закончены. Просто и эффективно, не правда ли?

Просто отдельный класс

Итак, мы решили отказаться от движков, требующих специальной инсталляции. Установка наших библиотек сводится к разархивированию или простому копированию. Пойдем дальше.

Движок должен быть инкапсулирован в отдельный класс. Он не должен иметь ветвистых зависимостей с другими модулями. Иначе устанешь их удовлетворять.

Множество хороших веб-программистов создавали и будут создавать свои, уникальные решения в рамках отдельных проектов. В таких случаях что-то непременно «затачивается» под конкретные нужды, что-то «дергается напрямую» и т. д. На базе таких решений вырастают системы публикаций или управления сайтами. Все это плотно упаковано, скручено в тугой узел, плохо отделимо друг от друга и, возможно, представляет собой законченный продукт, который, скорее всего, больше никому, кроме заказчика, не пригодится.

Если же речь идет именно о подсистеме для работы с шаблонами, то такая система должна представлять собой законченный интерфейс, отделимый от остальной системы. Фактически – уникальный класс либо модуль.

Программист, использующий движок, не должен тратить время на попытку понять, как оно должно было работать в соответствии с замыслом автора модуля или выполнять с десяток настроек. Нам нужен инструмент для работы, а не инструкция по обработке паровоза напильником с целью получить истребитель.

В нашем случае это требование выполняется полностью. Нам нужно просто подключить новую библиотеку, согласуясь с синтаксисом языка.

Библиотеку PHP XTemplate мы разместили в подкаталоге XTemplate каталога lib. Класс XTemplate содержится в файле xtpl.p.

Для того чтобы создать новый экземпляр класса, нам нужно подключить файл и создать объект:

<?php

...

include( getenv("DOCUMENT_ROOT")."/../lib/XTemplate/xtpl.p" );

$xtpl=new XTemplate( полное_имя_файла_шаблона );

...

?>

Для подключения библиотеки HTML::Template в Perl следует указать путь к её директории (если, как в нашем случае, она размещена отдельно от стандартных библиотек), подключить модуль и так же создать новый объект:

#!/usr/bin/perl

...

use lib $ENV{DOCUMENT_ROOT}."/../lib";

# Другой способ добавить каталог размещения библиотеки:

# unshift( @INC, $ENV{DOCUMENT_ROOT}."/../lib" );

use HTML::Template;

my $template = HTML::Template->new( filename => полное_имя_файла_шаблона );

Что же такое шаблон?

Вернемся к началу. Для чего затевалась вся эта история с шаблонами? В основном для того, чтобы отделить код HTML от кода программы. Идеальный шаблон – это файл, содержащий HTML-разметку, и программно заполняемый данными.

Одно из направлений в системах шаблонов – предварительная компиляция шаблонов в некоторое внутреннее представление. Обычно это убыстряет вывод программы, но любое изменение в шаблоне требует как минимум перекомпилирования его самого и, возможно, несколько зависимых шаблонов.

То есть никакое изменение в HTML-коде не может сразу отразиться на сайте. Пока такие системы не дают настолько ощутимого выигрыша в скорости, чтобы считать это действительно хорошим решением.

Так что сформулируем еще один постулат – движок не должен требовать дополнительной обработки шаблонов (читай – запретить предварительную компиляцию и прочие действия).