«Движок —
это звучит гордо»
Продолжая поиски методов решения своих технических проблем, Юзер обнаружит новое понятие — site engine, или, в отечественной интерпретации, «движок сайта». После этого он сильно задумается об очередном изменении внутреннего представления информации.
Итак, мысль первая: сохранение контента в виде html-файла разрушает его структуру. Например, попробуйте по исходному коду страницы восстановить имя ее автора (можно, конечно, использовать мета-теги, но вдруг при ручной правке их кто-то удалит — вид страницы не изменится, потерю данных можно не заметить). Не говоря уже о том, что в нашем случае информация будет вообще разбросана по нескольким файлам — содержанию, главной странице, возможно, некоторым другим.
Такая концепция никуда не годится. Юзер, скорее всего, слышал, что в подобных случаях используются загадочные базы данных, типа mySQL, но это страшно и сложно, и появляется другая мысль: ведь в любой операционке есть всем известная и хорошо освоенная БД — это обычная файловая система. Работает она быстрее, чем любая другая, к тому же ее древовидная структура подходит для проекта как нельзя лучше: рубрика ассоциируется с неким каталогом, опубликованные материалы — с содержащимися в нем файлами, а более мелкие разделы — с подкаталогами. Каждый файл может иметь простой формат, например стандартные поля «Заголовок», «Имя автора», «Аннотация», «Связанные ссылки», «Подключенные интерактивы» и т. д., разделенные каким-нибудь символом, — их будет легко изменять в редакторе вроде Notepad. Сам текст можно писать как обычно, с тегами не мучиться, но на всякий случай стоит расширить управление внешним видом с помощью опциональных html-команд.
Через некоторое время на свет появляется скрипт с именем engine.cgi. Он умеет из файлов нашего собственного формата делать вполне обычные веб-страницы — но с автоматической навигацией по рубрикам/каталогам, с гарантированно правильными ссылками, заданным оформлением и даже интерактивными вставками (например, оказывается, что при перемещении по сайту можно подсвечивать в строчке навигации название текущей рубрики — SSI такого не позволял). А посетители разницы, скорее всего, и не заметят — разве что адреса документов стали подлиннее, да обновляться сайт стал пооперативнее.
Для пущего удобства стоит сделать веб-интерфейс управления проектом — Юзер к нему еще по прошлой системе администрации привык, и редактирование файлов через ftp уже не кажется ему хорошей идеей. Он делает простенький файл-менеджер, заточенный под конкретный движок, — и тут наступает нирвана: управлять сайтом теперь совсем просто.
Нетрудно догадаться, что и это ненадолго.
Новые проблемы возникают, когда требуется в очередной раз изменить дизайн. Причем изменить совсем немного: колонтитулы остаются прежними, а вот элементы навигации — ссылки, баннеры, кнопочки — надо чуть-чуть подвинуть, что-то переместить на странице сверху вниз… И вдруг выясняется, что такой вот мелкий, локальный дизайн, в отличие от глобального «декора», так глубоко зашит в код (операторы вывода данных слишком тесно переплетаются с другими), что проще переписать скрипт заново, чем править его.
Дальше — больше. Engine.cgi постепенно превращается из обычной конверташки форматов файлов в настоящее средство доступа к «базе данных», а последняя тоже усложняется. В результате дизайн еще сильнее вписывается в код, и изменение его становится не проще аналогичной операции на первом этапе.
Появляются и новые требования: например, Юзеру хочется, чтобы на главной странице отображалось начало последнего опубликованного материала и самых популярных тем форума. Для этого нужно научиться сортировать все файлы (игнорируя их разделение по каталогам) по дате последнего обновления или количеству комментариев к сообщению.
Скрипт становится все более сложным и медленным, а посещаемость, не то к счастью, не то наоборот, растет по экспоненте — в результате загрузка процессора сервера быстро забирает положенные ей 5% и хостинг-провайдер грозится отключить сайт ко всем чертям, ссылаясь на какую-то строчку, набранную мелким шрифтом в договоре об обслуживании.
Кошмар, одним словом. А ведь все так хорошо начиналось…

«Баы данных — это не страшно, а XML — еще и модно»
Прогулка по форумам веб-программистов приносит новую порцию информации к размышлению. Оказывается, ни в коем случае нельзя выводить текст, одновременно выполняя другие действия, которые могут повлиять на вид страницы, — это нарушение принципа независимости дизайна и кода. Если говорить более конкретно, то для настройки оформления следует использовать шаблоны. Шаблон — обычный html-документ, каким он должен выглядеть при отображении, только вместо всевозможных непостоянных (то есть собственно информационных) элементов в нем записаны команды для программы-обработчика, которые при генерировании страницы заменяются нужной информацией. Плюс этого метода в том, что создать и, главное, модифицировать страницу могут даже дизайнеры, совершенно не знакомые с программированием. Однако и он не лишен недостатков: программный код и дизайн  это настолько разные это конструкции, что мы теряем последнюю надежду на их нормальное взаимодействие. В шаблоне нельзя создать цикл или поместить условный оператор, что серьезно ограничивает возможность управления видом страницы без модификации кода скрипта — так, если главная страница принципиально отличается по виду от остальных, придется делать для нее отдельный шаблон и отдельный обработчик в скрипте.
Вместо этого можно использовать, например, язык XML (eXtensible Markup Language, расширяемый язык разметки) совместно с XSLT (eXtensible Stylesheet Language for Transformations, расширяемый язык стилей для трансформаций). Первый представляет собой универсальное средство записи структурированной информации. По виду он весьма похож на HTML, а в реальности родственные связи между этими языками довольно запутаны, хотя есть и общий предок — SGML. Ну а XSLT — это язык преобразований документов из одного «диалекта» XML в другой². На выходе скрипта движка получаем XML-текст, не содержащий никаких конкретных инструкций по его оформлению, а затем, используя XSLT-замены, преобразуем его в обычный html. Несмотря на то что технологии, которые используются в этом случае, позволяют почти полностью контролировать и изменять внешний вид документа, не модифицируя сам скрипт движка (в гораздо более широких пределах, чем шаблонный подход), он имеет существенный недостаток: либо дизайнера надо учить XSLT, либо писать соответствующие инструкции по преобразованию XML в HTML самостоятельно. И то и другое довольно проблематично.
Вне зависимости от выбора технологий визуализации контент лучше все-таки хранить в базах данных, вроде MySQL. Эти базы на самом деле являются набором обычных таблиц, связанных перекрестными ссылками, и ничего страшного в них нет. Зато какое удобство доступа к информации! Специальный язык запросов позволяет извлекать записи, удовлетворяющие определенным, порой достаточно сложным критериям, сортировать их разными методами, производить поиск по всей базе и многое другое. Впрочем, и здесь не обходится без проблем — скорость выполнения запросов обычно не слишком большая, и, дабы не грузить сервер, придется использовать методы оптимизации — например, кэшировать полученную информацию в локальных файлах.
Скорее всего, имеет смысл заодно сменить и язык программирования — если раньше это был Perl, оптимальный для обработки текстов и извлечения из них информации, то теперь лучше использовать PHP — он изначально нацелен на работу с базами данных и вебом. С этим также связано огромное количество PHP-функций и библиотек, предназначенных для специфических операций при программировании сайтов, например поддержка тех же шаблонов. Впрочем, справедливости ради надо заметить, что удобство языка — вещь очень субъективная. Почти все, что можно сделать на одном языке, реализуемо на другом, и по многим параметрам Perl превосходит PHP.
И последнее. Если посещаемость сайта достаточно высока и ресурсы сервера не позволяют при открытии каждой страницы (то есть по несколько десятков тысяч раз в день) извлекать и обрабатывать информацию, то придется поступить следующим образом: весь контент, находящийся в базе, должен дублироваться в статических html-файлах, доступных для посетителей, а в задачи движка будет входить только поддержание этого статического «зеркала» базы в адекватном состоянии — то есть при любом изменении информации в БД он должен соответствующим образом перестроить все связанные страницы. На этом принципе работают сейчас многие крупные сайты.
Решение «PHP+MySQL» тоже не является совершенным в силу требовательности к ресурсам хостинга. Так что выбор технологии зависит от масштаба проекта — для создания домашней странички хватит и обычных статических файлов, а для небольшого контент-ресурса подойдет связка «CGI+SSI».
Автор благодарит Кирилла Тихонова за замечания по тексту статьи.

1 О том, что фреймы все-таки не стоило использовать, Юзер узнает потом — когда столкнется с проблемами индексации сайта, ссылок извне и т. д.
2 Или в обычный текст, или во что-то еще.