Как видите, в описанной ситуации off-line-сборка вполне оправданна, а такая ситуация возникает при поддержке практически любого ресурса в Web.

Вторая немаловажная область для применения техники off-line-сборки – разработка. Веб-дизайнер[1] должен иметь возможность оперативно глянуть на дело рук своих. Если его работа полностью сосредоточена на разработке шаблонов, сборка которых произойдёт только на сервере, то ему (на локальной машине) затруднительно увидеть результат своих трудов. Сперва он вынужден разместить всё на сервере, а это не только трудно, но и потребует от дизайнера квалификации, не свойственной для него.

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

То же самое относится и к верстальщику[2]. Ему было бы нелишне иметь возможность легко оценить, как будет выглядеть его работа в рамках общего дизайна (не «съедут» ли иллюстрации и таблицы, уместны ли цвета и т. п.).

Разработка тем более упрощается, если программист, дизайнер и верстальщик пользуются одним набором инструментов и одним форматом шаблонов.

Итак, задачи намечены, наметим теперь пути их решения.

Требования к аппарату off-line-сборки

Самые общие требования

n  Первое требование прозвучит почти комично: наша система сборки должна обеспечивать сборку. То есть она должна давать возможность описать, в какое место обрабатываемого файла содержимое какого файла будет вставляться.

Такие места вставки будем называть точками вставки. Получив возможность вставлять некую информацию во многие места многих файлов, мы получили возможность хранить одну информацию в одном месте. Это позволит и изменять (при необходимости) одну информацию в одном месте. То есть при последовательном проведении этой техники в жизнь вы сможете поменять название раздела в одном-единственном файле, одним касанием <Enter> пересобрать документы, и название раздела изменится во всех оглавлениях, заголовках, элементах <title>...</title> и во всех других местах, где встречалось это название. Так же можно будет менять цвета и другие элементы оформления. То есть ресурс становится предельно управляемым во всех отношениях.

n  Второе требование: программный код (код, выполняющий сборку) должен быть полностью отделён от кода шаблонов.

Это классическое требование, которое всегда предъявляется к обработчикам шаблонов и нарушается с таким же постоянством. Иначе и быть не может. С одной стороны, процессор шаблонов должен быть управляемым, то есть программируемым, иначе он сможет собирать только один документ по одному шаблону и утратит всяческий смысл. Но, с другой стороны, программный код в шаблонах должен, как мы только что сказали, отсутствовать. Этот парадокс каждый из разработчиков решает согласно своим задачам. Наши задачи таковы, что в шаблонах должен быть минимум управляющих конструкций. Мы намеренно не будем реализовывать ни переменных, ни условных переходов. Естественно, у нас не будет ни циклов (частный случай условных переходов), ни вычислений (направленных на обработку переменных)[3].