Динамические документы.
Что из себя представляет простейший сайт? Каждый кто сделал в своей жизни хотя бы одну страничку, уверенно скажет: "это несколько html-файлов и картинок, лежащих на сервере и связанных между собой гиперссылками". И каждый, кому приходилось производить на таком сайте какие-либо изменения, согласится с тем, что такой сайт крайне неудобен для обновления и поддержки.
Предположим, что в связи с наступлением нового года, вы хотите поменять на сайте шапку. Для этого вам нужно вручную произвести изменения на всех страницах сайта, не сделав нигде ни одной ошибки. А если вы захотели полностью сменить дизайн? Это равносильно тому, чтобы создать весь сайт заново, с нуля. Хорошо еще, если это небольшая домашняя страничка, состоящая из десятка небольших документов. Мне же, например, приходилось работать с корпоративным сайтом, примерный объем которого - порядка полутора тысяч страниц, причем все без исключения они представляли из себя самостоятельные html-документы.
Стоит ли говорить, что с весьма устаревшим дизайном этого сайта невозможно теперь что-либо сделать. Создание же нового сайта с переносом всей информации будет стоить конторе в сумму, которую изыскать она пока не готова.
Другая проблема - постоянное обновление информации. Даже на небольшом корпоративном сайте, допустим, при добавлении новости или очередного пресс-релиза, придется делать несколько изменений, причем прямо в html-коде, что исключает участие в непосредственной работе на сайте составителей контента, как правило менеджеров, и отнимает время у веб-мастеров или администраторов, зачастую занятых более важными вещами.
Ну и разумеется, никак нельзя обойтись статическими документами в случае, если на сайте планируется какая-либо обратная связь, допустим, комментарии посетителей по поводу той или иной статьи, или голосование. В блогах же, например, вообще весь контент состоит из сообщений, оставленных посетителями.
Таким образом, мы видим, что обойтись одними только статическими документами при создании современного веб-сайта в подавляющем большинстве случаев невозможно. Большая часть страниц, пусть даже с неизменным содержимым, все равно должна собираться динамически, из-за наличия меняющихся меню, элементов оформления и т.д. Такой сайт скорее представляет из себя не набор документов, а программу, работающую на сервере. Базовая часть этой программы, не зависящая ни от оформления, ни от конкретных данных называется движком сайта.
Хотя, вообще говоря, определение движка сайта весьма и весьма размыто. Этими двумя словами можно помимо всего прочего называть и простой механизм, благодаря которому осуществляется разделение контента и оформления. Этот механизм может вообще не использовать никаких скриптов на стороне сервера, а быть реализованным с помощью простых технологий, например SSI, по умолчанию поддержаемую веб-сервером Apache. Однако, все таки, чаще под словами "движок сайта" понимают нечто большее - систему, предоставляющую мощные и гибкие средства для публикации и управления содержимым (CMS), легко расширяемую, использующую базу данных и т.д.
Если говорить кратко, то CMS - это то, ради чего движок нужен людям, которые будут поддерживать сайт и делать для него контент. Обычно, она предоставляет средства для добавления, редактирования и удаления материалов на сайте, создания новых разделов, импорта информации из внешних источников и так далее. Система управления содержимым должна быть устроена так, чтобы управление информацией не требовало знаний html и знаний о внутреннем устройстве веб-страниц, что существенно снижает временные и финансовые расходы на поддержку сайта. Без CMS просто невозможно существование крупного проекта с солидным количеством материала, поэтому она является важнейшей частью и смыслом любого движка.
Сложность выбора.
В поисках готового движка вы неизбежно столкнетесь с проблемой выбора - бесплатных решений в Сети предостаточно, но как выбрать из них наилучший вариант? Для того, чтобы сравнить два движка по какому-нибудь критерию, необходимо понимать, для начала, какие вообще в данном случае могут быть критерии.
Обычно, движок - это набор скриптов, написанных на каком-либо скриптовом языке программирования, например php. Либо на "серьезном" языке, например С# или java, как opencms. Различия состоят в конкретных реализациях того или иного механизма, да в наборе функциональности доступной для движка.
Процессор шаблонов.
В основе любой системы, позволяющей управлять контентом сайта, лежит достаточно очевидный принцип разделения информации и ее оформления (в отличие от html-документа, где информация размечена тэгами, то есть, все лежит вперемешку в одном файле). Таким образом, организация такого разделения - главная часть внутренней архитектуры движка. Также, благодаря нему, достигается абстракция внутренней работы сайта от его внешнего вида, что и позволяет использовать движок в сколь угодном количестве похожих проектов.
Само собой разумеется, если оформление и контент разделены, то какая-то часть движка должна их собирать, чтобы показать посетителю сайта готовую страницу. Эту функцию выполняет процессор (или парсер) шаблонов - еще одна важная часть любого движка. Весь дизайн сайта хранится в виде шаблонов - составных частей конечных html-страниц. Они содержат html-код и код процессора шаблонов, синтаксис которого специфичен для каждого движка. К примеру, для того, чтобы вставить в шаблон список из множества элементов, необходим цикл, а для создания дружелюбного меню - еще и ветвление, сравнение каждого элемента с текущей страницей.
Вообще говоря, некоторые популярные, весьма неплохие решения, к примеру интернет-магазин Oscommerce, не имеют поддержки шаблонов. Оформление его страниц перемешано в php-скриптах вместе с кодом, что сильно затрудняет изменение внешнего вида. Вся информация, при этом, конечно же, хранится в sql-базе, благодаря чему разделение оформления и данных все же имеет место быть.
Структура данных и данные.
В нашем контексте, любой сайт - это информация, размещенная на его страницах. В случае статического сайта, состоящего из одних лишь html-документов, эта информация может быть совершенно различной, может не быть структурирована, может содержать разные типы данных и так далее. "Платой" же за удобства использования движка является вполне определенная структура данных, свойственная ему. Иными словами, вы никак не сможете прицепить к описанию товара в вашем магазине две картинки, если движок позволяет прицепить всего одну.
Логично предположить, что чем гибче и универсальнее структура данных, тем сложнее и запутаннее будет выглядеть окончательный вариант CMS. В пределе, в отсутствии какой-либо структуры, мы возвращаемся к сайту из html-файлов, со всеми его трудностями в плане поддержки.
Хранилищем информации служит база данных. Обычно, это какая-либо распространенная sql-база, но существуют и полноценные портальные движки использующие в качестве хранилища текстовые файлы (GuppY
, Siteman
). Главное преимущество "нормальной" базы - это высокая производительность, а также гарантии целостности данных. Из плюсов текстовой базы можно отметить разве что лишь дешевизну хостинга (тарифные планы без базы обходятся дешевле стандартных), да еще, в некоторых вариантах, - возможность непосредственного доступа к информации путем простого редактирования файлов.
Другие функции.
Прочие функции движка можно назвать дополнительными, несмотря на то, что они бывают не менее важны для проекта, и их отсутствие может стать критичным.
Поиск на сайте. В случае, если вам нужен небольшой сайт, с малым количеством информации, поиск по нему скорее всего не понадобится. Несколько разделов с тектовыми материалами, иллюстрациями, несколько табличек - искать просто-напросто нечего. Однако, если вы создаете, к примеру, архив статей по определенной тематике, то без поиска вам никак не обойтись.
Поиск может быть реализован по-разному, в зависимости от типа основной информации. Поиск по форуму, например, имеет одну, вполне определенную форму, в которой, как правило, предлагается найти сообщения какого-либо автора, в заданном промежутке времени, содержащие определенные слова. В написанном же недавно мною движке была предусмотрена возможность создавать множество разнообразных небольших форм поиска и подставлять их в любое место любого шаблона.
Возможности аутентификации. Вообще говоря, наличие CMS, как правило, сразу предполагает как минимум две роли на сайте - посетитель и администратор. Поэтому, в данном случае, под словом "аутентификация" я понимаю наличие регистрационных записей пользователей и возможности распределения прав доступа к разделам сайта между группами пользователей. Разумеется, движки блогов и форумов, например, вообще не могут обойтись без функции авторизации, однако для многих других типов сайтов она совершенно не нужна.
Для движков, скажем, новостных сайтов, жизненно важно иметь грамотно продуманные средства кэширования. Как правило, движок кэширует конечные страницы, например, сохраняя их в виде статических документов, которые и выдаются пользователю. Некоторые системы умеют кэшировать результаты запросов в базу данных, а некоторые даже результат работы отдельных кусочков кода.
Не стоит забывать также, что при кэшировании между внесением изменений в данные или оформление и фактическим их появлением на конечных страницах появляется тайм-аут, равный времени обновления кэша. Казалось бы, что может быть сложного в том, чтобы заново сгенерировать страницу? Не стоит, однако, забывать про то, что, добавленная новость, например, должна появится в менюшках и анонсах на множестве других страничек, которые тоже придется пересобрать.
Установка.
Большинство бесплатных решений, из попадавшихся мне, были весьма просты в установке. Скачайте себе архивный файл, распакуйте его, найдите руководство по инсталляции и внимательно прочитайте его. В любом случае, для начала необходимо залить распакованный архив в рабочую папку на сервере. Как правило, разработчики движка, понимая, что работать с ним будет человек, не сильно искушенный в программировании и администрировании баз данных, пишут специальный мастер установки, запускаемый через браузер, так что вам остается только заполнять формочки нужной информацией и нажимать "Ок".
Для установки большинства движков вам потребуется вводить вполне очевидные настройки, например, адрес электронной почты администратора, название ресурса, его URL и так далее. Если выбранный вами движок использует базу данных, то далее возможны два варианта.
Первый вариант - мастер установки сам создаст в базе необходимую ему структуру данных. В этом случае, вам нужно, во-первых, убедиться, что хостинг, который вы приобрели, включает в себя услуги предоставления базы данных, а во-вторых, выяснить ее настройки: IP-адрес или имя хоста, к которому будут обращаться скрипты, имя базы данных, логин и пароль. Эти настройки вам должен предоставить хостер. Возможно, вас спросят, какой вы желаете указать префикс для названия таблиц в базе. Это опция необходима, если возможности хостинга позволяют вам иметь только одну базу данных, а сайтов, использующих ее, хочется иметь несколько. Префикс необходим для того, чтобы избежать конфликтов имен таблиц, принадлежащих разным движкам.
Второй вариант сложнее. Если в мастере установки не реализована возможность создания необходимой структуры данных, либо, по каким-то непонятным причинам, база данных не создается, вам придется создать ее вручную. Предоставляя вам услуги доступа к базе данных, любой хостер не может не предоставить и средство ее администрирования. В подавляющем большинстве случаев такой sql-базой является MySQL, а средством ее администрирования - веб-приложение PhpMyAdmin. Таким образом, вам необходимо отыскать среди большой кучи файлов движка нужный вам файл с полным sql-запросом (еще раз внимательно изучите руководство по установке, если такой файл существует, то его местонахождение там указано), и затем запустить его из PhpMyAdmin.
Если же никакого мастера установки в движке не предусмотрено, то общий совет по установке может быть только один: скорее всего, все необходимые настройки прописываются в конфигурационном файле или файлах. Следуйте инструкциям в прилагаемых с движком файлах, либо найдите руководство по инсталляции на сайте, с которого вы скачали движок.
Движок, представляющий из себя простой набор скриптов, прост в установке и дает вам возможность вольготного выбора хостинга. Его нетрудно слегка исправлять и править "под себя", так как он написан на распространенном и наверняка знакомом вам языке. Разумеется, есть у такого подхода и недостатки. Самым главным недостатком лично я считаю то, что любой такой движок слишком жестко привязывает владельца сайта к своей структуре данных и к своему способу подачи информации. Это, с учетом того, что найти движок абсолютно точно соответствующий вашим потребностям практически невозможно, может стать весьма неприятным. С другой стороны, написать свою систему "с нуля" далеко не всегда представляется целесообразным.
Часто такая проблема возникает при создании вертикального портала, то есть, портала по какой-то определенной тематике, когда на сайте необходимо реализовать специфический набор конкретных функций. Именно поэтому наиболее распространенные портальные движки построены по модульному принципу, то есть, в сам движок выполняет лишь базовые функции, о которых я писал выше, а разнообразный набор возможностей заключен в модулях, которые можно к нему подцеплять. Разумеется, таким образом можно построить сайт любого типа, не только портал. Хорошими примерами таких бесплатных движков являются популярный и простой php-nuke
, его клон, postnuke , хорошо защищенный e107 , очень гибкое и качественное решение Xaraya - список можно продолжать довольно долго.
Ко многим из них можно дописывать свои собственные модули и реализовывать дополнительную функциональность самостоятельно. Кроме того, в случае использования особо популярных движков, написания модулей от вас и не потребуется - их можно скачать в Сети и начать использовать, предварительно установив и настроив.
Низкие уровни реализации двигателя.
Далее я хотел бы рассказать о программных продуктах, которые используют качественно иной подход, нежели наборы скриптов. В сущности, это скорее не движки, а решения, которые помогут вам создать свой собственный динамический сайт быстрее и проще, нежели с использованием общепринятых технологий.
Например, детище Студии Лебедева - Parser. По большому счету, Parser - это очень сильно модернизированный процессор шаблонов, то есть, одна только часть "обычного" движка. Однако возможности этого процессора шаблонов весьма и весьма впечатляют. Во-первых, изменяется сам принцип публикации документов - Parser можно назвать объектно-ориентированным языком, и вложенные страницы могут, что называется, наследовать от родительских все, вплоть до содержимого. Кстати, именно в Parser'е реализовано кэширование отдельных фрагментов кода, о котором я упоминал выше. Есть и одно важное "но": так как это именно язык, то, разумеется, в нем нет ни структуры данных, ни, соответственно, CMS. Поэтому эту весьма важную составляющую серьезного движка вам придется написать самостоятельно, если вы, конечно, не считаете что можете без нее обойтись. У Parser'а весьма оригинальный синтаксис, удобство и читаемость которого довольно спорны. Впрочем, разобраться в нем достаточно легко. На сайте www.parser.ru вы сможете скачать всю необходимую документацию, написанную толково и лаконично.
Главная проблема, которая встанет перед вами, если вы надумаете использовать Parser - это хостинг. В идеале, Parser устанавливается как модуль к веб-серверу Apache, однако для этого вам скорее всего потребуется наличие в Интернете собственного сервера. Существует и решение данной проблемы - Parser можно установить как cgi-приложение, скачав бинарный файл, соответствующий операционной системе хостера, и поколдовав немного с .htaccess. В результате, вы проиграете в быстродействии и лишитесь некоторых возможностей кэширования, однако, во многих случаях, это не имеет особого значения. Таким образом, можно считать Parser практически идеальным инструментом для быстрого создания небольших и несложных сайтов.
Другой оригинальный и довольно популярный продукт - это Zope. Разработчики Zope пошли дальше Студии Лебедева и написали полноценную платформу, объединяющую веб- и ftp-сервера, простую sql-базу, процессор шаблонов и много других интересных и полезных вещей, перечислять которые здесь не имеет смысла. Стоит остановится на нескольких ключевых моментах. Во-первых, любой сайт на Zope состоит не из иерархии файлов, а из иерархии объектов. Объекты могут быть самыми разнообразными, например шаблон, файл CSS, или, что уже довольно необычно, соединение с базой данных или какой-то sql-запрос, привязанный к нему. Таким образом, программирование конкретных функций вашего сайта на Zope производится буквально мышью. Практически все остальное программирование приходится на долю процессора шаблонов - zpt или dtml. Процессор, используя созданные вами запросы, заполняет шаблон инфомацией из базы данных, либо, таким же образом, вставляет ее туда.
Возможности Zope, конечно же, не исчерпываются тем, что я описал в абзаце выше. Это очень мощный продукт, на котором можно создавать сайты любой сложности. Zope предоставляет гибкие возможности кэширования и систему аутентификации, а также множество уже написанных бесплатных модулей, среди которых можно встретить, например, полноценный портал с CMS и многое другое. Среди минусов платформы, самым главным является обязательное наличие специализированного хостинга, который нелегко найти.
