Обработка HTML-шаблонов off-line. Возможности и ограничения

Алексей Мичурин

Сборке HTML-документов по шаблонам посвящено великое множество публикаций самого разного масштаба и качества: от небольших статей до детальных руководств и книг, от дилетантских до весьма профессиональных. Но подавляющее большинство авторов сосредоточивается на on-line-сборке. Ими рассматривается ситуация, когда на сервере лежат не статические документы, а шаблоны: заготовки и части документов. При запросе клиентом соответствующей страницы на сервере запускается некий механизм, собирающий веб-страницу «на лету» (в реальном масштабе времени) и отправляющий её клиенту. Для решения подобных задач разработано множество инструментов и средств, начиная с несложных и интегрированных глубоко в сервер (например, SSI) и заканчивая многофункциональными самостоятельными модулями и библиотеками с очень богатыми возможностями.

Тема on-line-обработки шаблонов действительно очень интересна и воистину неисчерпаема, поскольку в разных условиях оказываются уместны разные подходы. Неудивительно, что так много авторов обращается именно к этой теме. Но я хотел бы уделить немного внимания механизмам off-line-сборки. Возможно, не слишком распространённым термином «off-line-сборка» я буду называть процесс сборки шаблонов на локальной машине, в отсутствие серверного ПО и не для передачи клиенту. В результате такой сборки вы получаете набор статических документов (хотя никто не запрещает использовать, например, SSI-инструкции), готовых к размещению на сервере. Оказывается, концепция сборки документов по шаблону может быть весьма полезна не только при сборке документов «на лету», но и при сборке статических документов.

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

Когда применима off-line-сборка?

Ценность автоматизации сборки статических документов может показаться неочевидной, но это только на первый взгляд. Да, off-line-сборка позволит создавать только статические документы. Приёмы, которые мне предстоит описать, ни в коей мере не связаны с «on-line-движками». Тем не менее, разработка статических документов – неотъемлемый и трудоёмкий процесс, неизбежно сопровождающий создание и поддержку любого веб-ресурса. Облегчению этой задачи и посвящена настоящая статья. А прежде чем привести два примера, замечу, что техника, изложенная здесь, может применяться и для создания частей документов, которые далее будут использоваться как исходные данные для «on-line-движков».

Приведу два, как мне кажется, наиболее житейских примера.

Практически у любого ресурса есть страницы, которые обновляются редко, но время от времени обязательно обновляются. Это могут быть адреса торговых точек и филиалов, телефоны, расписание работы, информация о сотрудниках, подборки статей и многое другое. Эти страницы, скорее всего, должны быть оформлены в едином стиле с содержимым всего сервера, то есть включать стандартную шапку, элементы навигации и прочее. Невольно появляется мысль использовать для их создания технику сборки по единому шаблону. Вместе с тем, на практике эти страницы несут статическую информацию. Собирать их вновь при каждом запросе не очень разумно. Гораздо рациональней – собрать их единожды и разместить на сервере, а при необходимости вносить малые изменения в шаблоны, легко пересобирать необходимые страницы и размещать их на сервере. Возможно, необходимость проведения таких работ будет возникать раз в несколько лет, но даже редкую работу лучше делать просто, чем сложно.

Здесь возникает возражение: такой поход прожорлив до дискового пространства. Соглашусь с этим, но отвечу, что дисковое пространство стоит копейки и обходится гораздо дешевле процессорного времени, за одну только возможность использования коего обычно приходится дополнительно доплачивать. При отказе от on-line-сборки в пользу off-line-сборки мы проигрываем в дисковом пространстве, но объем трафика (гораздо более важная характеристика) не меняется, а процессорное время (тоже весьма важная характеристика) существенно экономится. Таким образом, суммарно мы, скорее всего, получим выигрыш. (Вопросы трудоёмкости загрузки большого объёма данных на сервер и другие вопросы я обязательно затрону, но ближе к концу статьи.)