Автор: Олег Титов (oleg@digin.ru)
Источник: Весь хостинг и Все о хостинге
Не спеши, Паровоз
Хотим сделать сайт, уже знаем о чем он будет, для кого он будет и
что там будет. Не знаем только одного - как и с помощью чего будем его делать. Давайте
разберемся сейчас, чтобы не было мучительно больно потом.
Благими намерениями...
Все, даже господин Лебедев, когда-то начинали. Все мы открывали блокнот, писали в него
строчку <html> и надолго задумывались "а что, собственно, дальше?". А дальше надо
действительно подумать, хорошо подумать, так как помимо идеи сайта, материалов, кучи
различного софта и неуемного энтузиазма, надо продумать механизм сайта. Или, говоря по
новомодному, "движок". В самых простейших случаях можно конечно обойтись и без него, то есть
сотворить некую структуру, обозвать структурные единицы разделами, забить под завязку эти
разделы нужной и полезной информацией, поставить на сайт голосование, форум, гостевую,
счетчики от сторонних ресурсов. Потом связать все это хозяйство в единый организм сотней
перекрестных гиперссылок и залить получившийся шедевр на сервер. Замечательно! Что-же мы
такое сделали? А сделали мы себе очень большие проблемы. Представим себе такую ситуацию: на
нашем сайте около сотни страниц (пусть даже не сотня, а всего десять), разделенных по десяти
разделам. Половина из всех наших страниц в организованном беспорядке напрямую ссылается на
другие страницы (ссылки вида http://www.yourserver.ru/section/info.html), а на другую
половину можно попасть только из страниц из первой половины. И вот у нас назрела
необходимость один, самый большой и грандиозный раздел, поделить на три поменьше. Разделили,
но что это? Посетители начинают нас заваливать письмами о том что не могут найти тот
материал, этот. Страница с ошибкой 404 (страница не найдена) становится самой посещаемой у
нас на сайте (впору на ней баннеры крутить). Что нам приходится делать? Идем по всей своей
сотне страниц и правим внутренние ссылки, проверяем и снова правим, потом снова правим и
снова проверяем. Спустя пару дней сайт снова работает как часы, все ссылки верны и посетители
больше не ругаются. А неделей позже мы добавляем пару новых материалов, новый раздел и
начинаем проходить все круги ада по новой. Заканчивается все это рано или поздно всегда
однинаково: сайт перестает обновляться, а его владелец, сказав "А ну его, мы лучше наш, мы
новый мир построим", переезжает но новый адрес и лепит очередной шедевр, который, если
вебмастер не сделал надлежащих выводов, ждет судьба предыдущего. Знакомая ситуация? Лично мне
года три назад, когда я не знал даже азов веб-программирования, приходилось практически
ежедневно обновлять проект, состоящий из более чем сотни страниц в семи разделах. Я
продержался три месяца. Поэтому, если ваш проект будет размером больше 10 страниц и вы
собираетесь его дальше развивать, в первую очередь необходимо продумать навигацию на сайте,
вывод материалов, организацию перекрестных динамических ссылок и массу других мелочей. А
толково организовать все это хозяйство можно с помощью какого-либо языка программирования,
технологии SSI и прямых рук (наличие последних есть необходимое, но не есть достаточное
условие). Вот и посмотрим, как нам такой механизм организовать.
Чтобы что-то
сделать, надо знать что именно
Для создания "движка" сайта нам понадобится любой язык
программирования (Perl, PHP, ASP, JSP,...), и, если есть такая возможность, SSI и доступ к
любой базе данных. В этой статье я не буду касаться технической стороны создания механизма, в
этой статье я расскажу о том, что это должен быть за механизм, какие функции он должен
выполнять и какую выгоду мы от этого получим. Начнем с определения целей, ради которых будут
ломаться копья:
• одинаковый стиль дизайна для всех страниц и смена дизайна всего
сайта за 5 минут;
• доступность любого материала при его логическом перемещении в
любое место сайта без какой-либо правки ссылающихся на него страниц;
• легкость и
оперативность изменения любых материалов и настроек структуры сервера через веб-интерфейс;
• безболезненное добавление новых материалов в уже сложившуюся структуру сайта;
• полный учет и статистика перемещений пользователя по внутренним ссылкам сервера и
выхода за его пределы.
Задачи поставлены, теперь разберемся с их решением. Вообще
говоря есть три принципиальных пути, первый с использование шаблонов и языка
программирования, второй - с использованием SSI, а третий является комбинацией двух первых.
Мы рассмотрим первый вариант, тк о втором я расскажу подробно в другой статье, а третий, на
мой взгляд, весьма неоднозначен.
Физика и лирика
Шаблон - наше
спасение. Поясню на примере: у нас есть некий раздел с десятком-другим статей, дизайн этого
раздела не меняется от статьи к статье, так зачем нам держать для каждой статьи отдельную
страницу, занимая место на сервере и создавая себе вышеописаные проблемы? Правильно, незачем.
Поэтому для этого раздела мы создаем шаблон, в нем в то место, где будет выводиться сам текст
статьи вставляем самопальный тег типа <ARTICLE> и сохраняем полученное творение под
именем article_template в директорию на нашем сервере. Затем пишем небольшой скрипт
viewarticle.cgi, который, в зависимости от передаваемых ему данных, будет брать этот файл
article_template, искать в нем тег <ARTICLE> и подставлять вместо него статью, ID
которой этому скрипту был соответственно передан в запросе вида
http://www.yourserver.ru/cgi-bin/viewarticle.cgi?id=XX, где XX - номер запрашиваемого
материала. А сам материал тем временем в виде обычного тексотового блока (может быть даже
приправленного html-тегами) лежит себе в базе данных. И все, если статья была успешно
извлечена из своего хранилища и не менее успешно подставлена вместо тега <ARTICLE>,
можно совершенно спокойно выдать пользователю получившийся документ. Просто? Очень! Таким-же
образом можно обрабатывать например теги <COUNTERS> для подставления кода счетчиков,
<MENU> для навигационного меню, <VOTE> для вывода голосования и любые другие
уникальные теги для других целей. Аналогичным образом можно написать шаблоны для абсолютно
всех страниц сайта. Надеюсь не нужно обьяснять, что каждый материал должен иметь свой
уникальный ID. А сейчас посмотрим что еще полезного можно сделать на основе нашего механизма.
Ну, во-первых, можно максимально оперативно добавлять, редактировать и удалять любые
материалы (если соберетесь удалять, поставьте вместо тела удаленной статьи небольшое
обьяснение пользователю, что и почему удалили и где можно найти этот материал сейчас, или
просто расскажите анекдот:)). Во-вторых, можно не беспокоиться за вызов этого материала из
любой точки сайта или вообще сети, так как адрес у нее теперь один на века. В-третьих,
графическое оформление всех материалов всегда будет соответствовать общему дизайну сайта,
так как поменять дизайн одного шаблона в тысячу раз проще чем дизайн тысячи страниц.
В-четвертых, если вы дополните свой механизм несложной системой статистики, вы будете знать
про свой сайт все: кто, куда, откуда и зачем пришел. В-пятых, вы навсегда избавитесь от
ошибки 404 на своем сайте, так как в любой момент сможете контролировать своиства всех
внутренних ссылок на вашем сайте. Можно привести еще аргументы, и шесть, и семь, и еще много,
но разве уже приведенных недостаточно?
...То и полюбила!
Если
немного пошевелить мозгами и руками, можно достаточно быстро создать очень удобную систему
управления своим сайтом. Вы поразитесь тому, как вы раньше жили по другому. Ваш сайт будет
работать как часы даже в период глобальных изменений, и ни один посетитель не уйдет
разочарованным.
|