Свежепосвященный в вебмастеры Юзер в самом начале своей деятельности сталкивается со множеством непонятных терминов и аббревиатур, от которых голова идет кругом. Возникают вопросы: что лучше — www или http, действительно ли скрипты — это те же теги, только крупнее, можно ли бесплатно зар
гистрировать домен первого уровня, зачем нужен jpg, если есть Photoshop, и множество других. Юзер с удивлением обнаруживает, что вебмастеринг — это далеко не так просто, как казалось.
Однако на помощь приходят современные технологии: визуальные html-редакторы, шаблонные генераторы страниц, популярные на бесплатных хостингах, а также веб-панели управления и другие подобные вещи.
Всего за неделю в программе FrontPage (обычно), DreamWeaver (в продвинутых случаях), Word (в безнадежных случаях) или веб-редакторе хостинга создается десяток страниц, одна из которых гордо называется Главной, а несколько других представляют собой содержание основных рубрик проекта. Затем все они связываются сетью гиперссылок, на них в беспорядке вешаются картинки и кнопки, выбирается какой-нибудь замысловатый фон — и сайт, кажется, готов к запуску — без единой строчки кода, написанной самим Юзером.
«Ура! — говорит Юзер. — Как хорошо, что мы живем в мире, в котором вебмастер может забыть о технических трудностях и сконцентрироваться на содержании».
Первое недовольство возникнет, скорее всего, при втором-третьем обновлении, когда окончательно станет ясно, что при публикации очередного материала приходится выполнять немаленькую работу: сверстать страницу в html-формате, поместить ее на сервер, дать аннотированную ссылку из содержания рубрики, в которой она публикуется, сообщить о появлении материала на Главной странице в разделе «Новости», изменить другие связанные страницы (установив перекрестные ссылки); при этом все страницы нужно снова закачать на сервер, все ссылки проверить на правильность (а трудно ли ошибиться, если index.html почему-то оказывается не тем же, что Index.html, и последний сильно отличается от Index.htm?), а при нахождении, не дай бог, ошибки — исправить оба варианта страницы: и тот, что на сервере, и тот, который на домашнем компьютере. Публикации и обновления материалов превращаются в кошмар, сравнимый разве что с уборкой на рабочем столе (реальном или компьютера), и это только начало.
Через две недели работы Юзер понимает, что внутреннюю структуру сайта надо слегка поменять — несколько рубрик объединить в одну, из другой сделать новый крупный раздел с разбиением на подразделы и т. д. Если Юзер оказался не слишком прилежным и не внял советам не строить навигацию на фреймах, он сейчас обрадуется своей непослушности — достаточно будет лишь поменять файл, соответствующий списку рубрик, да перестроить страницы-содержания. В противном случае придется менять все страницы — ведь на каждой есть столбик со ссылками на рубрики. Некоторым облегчением сего действия может стать использование шаблонов при разработке (в DreamWeaver или, возможно, FrontPage), но и в этом случае все файлы придется закачивать заново.
Проходит три дня. Юзер завершает изменение навигации. Вот уже последний файл «слит» на сервер, все ссылки проверены на работоспособность, а новая структура радует глаз своей стройностью. Кажется, что совершать подобные подвиги не придется еще много лет.
Телефонный звонок. Юзер снимает трубку, сначала радостно улыбается, потом бледнеет и падает в обморок: знакомый нарисовал новое оформление для сайта. Это было бы хорошо — старое, как теперь очевидно, оставляет желать лучшего — жутко непрофессиональное, шаблонное, с набившей оскомину графикой из бесплатной библиотеки, с торчащими откуда-то кусками таблиц и периодически съезжающим вбок текстом, и его пора сменить на что-нибудь красивое и оригинальное… Но ведь придется редактировать все файлы и закачивать их на сервер. Снова!!!
“Почему мне раньше никто не сказал про SSI и CGI?”
Через какое-то время после полного разочарования в статических веб-страницах и визуальных редакторах Юзер узнает, что SSI — это не страшный монстр, а, скорее, добрая и милая собачка, которую надо только приручить, и она начнет верой и правдой служить своему хозяину. SSI расшифровывается как Server Side Include, то есть включение на стороне сервера, и позволяет собирать страницу из отдельных кусочков, подключая к одним файлам другие. Узнав про это, сообразительный Юзер быстро понимает, что любая страница на его сайте представляет собой эдакий «слоеный пирог» — собственно текст материала оказывается зажат между верхним и нижним колонтитулом, причем последние одинаковы на всех страницах, и посему их можно достаточно легко вынести в отдельные файлы, а затем подключать SSI-инструкциями.
Вооружившись текстовым редактором (визуальные уже неприменимы, поскольку они предпочитают работать с целостными html-документами, а не с «SSI-нарезкой»), Юзер кромсает файлы своегосайта,заменяякод,относящийсякдизайну(тесамыеколонтитулы),накомандывида<—#includevirtual=«/top.txt»—>. Реализуется идея разделения содержания и формы: в файлах остается только контент, а дизайн настраивается через изменение SSI-вставок. Теперь можно одним движением мыши сменить оформление и навигацию на всем сайте. И верстка страниц становится сплошным удовольствием — не надо путаться в коде всяких таблиц и ячеек, достаточно заменить в обычном txt-файле символы новой строки на тег да добавить в начало и конец файла инструкции на вставку верхних и нижних колонтитулов. Заодно Юзер постепенно обучается языку HTML, и у него появляется ни с чем не сравнимое чувство свободы и полного контроля над ситуацией — теперь можно самому писать код страниц, а не надеяться на визуальный редактор. Благодать, одним словом!
Благодать-то она благодать, но перейдя на модульную конструкцию страниц, мы решили только часть проблем — при публикации новых материалов все равно полсайта приходится менять вручную и перезакачивать на сервер, и тут уж никакой SSI не поможет.
Что же делать? Очевидно, автоматизировать процесс! В поисках средств для этого Юзер рано или поздно натыкается на CGI-скрипты. Они представляют собой программы, которые запускаются и работают на стороне сервера, взаимодействуя с пользователем через браузер. Информация вводится в такой скрипт путем заполнения веб-формы, обрабатывается им, а затем результат выводится посетителю в виде динамической страницы. Это достаточно гибкий и универсальный инструмент, с помощью которого можно автоматизировать рутинные действия.
В течение недели осваивается, например, Perl и пишется (или где-то берется) несложная программа, которая запрашивает через веб-форму параметры материала: рубрику, заголовок, имя автора, сам текст, аннотацию и т. д., затем записывает введенную информацию в уже сверстанном виде в новый файл, проставляет на него ссылки в других файлах и делает всю остальную нудную работу. Может даже подготовить выпуск почтовой рассылки, если сайт Юзера уже успел ею обзавестись.
Более того, оказывается, что с помощью CGI можно делать еще много хороших вещей — начиная от вставки в страницы, например, случайной ссылки из коллекции и заканчивая гостевой книгой или даже баннерной сетью.
Связка «SSI+CGI» может работать долго и успешно. Но если проект растет, он начинает предъявлять новые требования к системе управления. Сайт становится сложнее по структуре и, главное, по динамике — материалы изменяются в реальном времени, между ними появляются связи, увеличивается количество интерактивов (форумов, голосований), возможно, к проекту подключаются новые люди, которые хотят получить прямой доступ к сайту и самостоятельно редактировать контент. И тут оказывается, что любое изменение, кроме тривиальной публикации, до сих пор не было автоматизировано, да и сделать это с технологией хранения информации в статических html-файлах принципиально невозможно!
«Движок — это звучит гордо»
Продолжая поиски методов решения своих технических проблем, Юзер обнаружит новое понятие — 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. Или в обычный текст, или во что-то еще.
Илья Щуров
offline.computerra.ru