Здравствуйте, уважаемые подписчики! Рассылка долго не выходила, так как никак не удавалось сесть за написание новых материалов. За это время произошло многое, у нас и сайт открылся. Потом правда закрылся, а посему и хвастаться нечем. Но руки пока не опускаются, я продолжаю работать и писать. Сегодня я включил в выпуск новую статью для тех, кто собрался сесть за написание собственного движка для сайта.
---
Наверх

Я, пожалуй, не смогу точно ответить на вопрос, что именно сподвигло написать меня эту статью. Скорее всего, стимулом к данной работе послужило мое давнее стремление выпустить хороший, конструктивный материал. Именно конструктивный, так как с при общении с некоторыми "PHP-программистами" возникает твердое ощущение, что им не мешало бы с чем-то подобным ознакомиться. Вообще я всегда крайне осторожно употребляю термин "программист", несмотря на то, что это слово является одним из самых популярных в среде авторов статей на программистские темы. Что поделать, так уж повелось. На HTML у нас пишут программисты, программисты устанавливают готовые движки за деньги, программисты там, программисты сям. Спросишь, бывало, у администратора какого-нибудь крупного портала, один ли он работает, и в ответ тут же услышишь о существовании целой команды, потеющей над данным ресурсом. Поинтересуешься, что да как, а тебе отвечают, дескать, там у нас и дизайнер, и куча модераторов, и программист. Все бы хорошо, да только в большинстве случаев речь идет о порталах на коммерческих движках, купленных или украденных - не суть. И чем же занимается программист? "Натягивает" оформление на готовый продукт? В своих статьях я обычно стараюсь идти на компромисс и обхожусь такими терминами, как "начинающий программист" или просто "вебмастер". Так правильней, пускай даже кто-то и оспорит смысл, вкладываемый мной в понятие "вебмастер".

Конечно, PHP относят к языкам веб-программирования, но не следует думать, что веб-программирование чем-то хуже локального и называть веб-программистами кого не попадя. Так уж вышло, что эта ниша компьютерной индустрии на порядок легче в освоении, которое часто бывает поверхностым. Но и таких неглубоких знаний обычно хватает, чтобы написать некоторый скрипт (даже на заказ) и приклеить себе ярлык "веб-программист". К чему я все это рассказываю? Если вернуться к названию статьи, то станет ясно, что тема моего повествования вовсе не брызжание слюной по поводу терминологии, а написание CMS. Однако такая прелюдия была, на мой взгляд, необходима, ибо речь пойдет о том, как написать CMS без посторонней помощи и готовых материалов. Я ни в коем случае не буду утверждать, что после прочтения этой статьи Вы получите базу для создания собственного движка, так как преследую совершенно другую цель - рассказать о том, как лучше поступать при написании такой сложной системы, как CMS, чтобы потом можно было с гордостью сказать: "Да, я веб-программист". А для этого, как мне решительно кажется, писать движок нужно только своими силами и с нуля.

Возможно, кто-то из читателей тут же подумает, дескать, зачем изобретать велосипед? Ведь есть уже куча готовых компонентов, из которых можно собрать действительно достойный программный продукт. И это при том, что такая "сборка" - занятие отнюдь не легкое. В процессе Вам потребуется многое узнать и освоить, чтобы на выходе получить не какого-то там франкенштейна, а хороший и удобный движок. Но это не программирование. Задействовать чужие куски кода при написании своего первого (если подходить к вопросу слишком уж лояльно) движка непозволительно веб-программисту, если тот же самый код он не в состоянии написать сам. Конечно, говорить легко, ведь бывают такие ситуации, при которых либо времени катастрофически мало, чтобы ваять нечто рукотворное, либо голова уже опухла настолько, что никаких новых идей не рождается, а написать самому не получается ну никак. Первый довод я оставлю без внимания, так как речь идет о другом, а второй действительно весомый. Я, например, еще долго буду помнить 2 бессонных ночи, просиженных за реализацией одной прикладной программы. Ведь все шло замечательно, пока я не наткнулся на один момент, испортившый кучу нервов и убивший много времени. Похожая ситуация у меня была и при написании собственной CMS. Так как здесь речь идет уже не о локальном программировании, то я могу смело назвать проблему, на решение которой пришлось потратить целый вечер: реализация постраничного вывода новостей. Т.е., у Вас есть, скажем, 20 абзацев текста и Вы хотите, чтобы на одной "странице" выводились только первые десять. Ниже будет ссылка на вторую страницу, нажав на которую, появляются абзацы с 10-го по 20-й. Ну, и таких страниц гипотетически может быть бесконечно много. Я клоню к тому, что иногда возникают ситуации, настолько изматывающие программиста, что хочется плюнуть и поискать готовое решение. Зачем? Чтобы потом, просматривая код, ударить себя по голове с криком "Ах, точно! Я был так близок!", только и всего? Нет ничего лучше момента, когда ты сам, наконец, добиваешься нужного результата. И чем больше времени на это потрачено, тем сладостней упоение и, что самое важное - глубже знания. И я смело могу сказать, что решение таких нелегких проблем - это одна из непосредственнх задач программиста. Если программист не сталкивался с такими проблемами и не выходил из них "победителем", то разве может он называть себя программистом? По-моему нет.

Ниже я привел небольшой список задач, которые предстоит решить каждому человеку, взявшемуся за написание тривиального движка. Список получился достаточно сжатым, но от его содержания можно отталкиваться при добавлении новых функций. Иначе говоря, я привел лишь необходимый минимум. Наряду с реализуемой задачей я отметил ее объективную сложность, а в крайне правом столбике - мои личные ощущения.

Задача для программиста	Уровень сложности	Субьективные впечатления
Главное меню	Достаточно просто	Легко
Новостная лента	Сложно	Трудно
Система статей	Достаточно просто	Средне
Система комментариев	Достаточно просто	Средне
Администраторская панель	Сложно	Средне
Гостевая книга	Сложно	Средне

Теперь поговорим о каждой задаче в отдельности. Если описывать их по порядку, то сначала речь пойдет о реализации панели навигации движка. Принцип ее построения прост и в ходе реализации никаких особых проблем возникнуть не должно. Первым делом опишем проблему, которую предстоит решить. Итак, меню - это не только список пунктов, вроде "Главная | Об авторе | Гостевая Книга", но и, если это нужно, список подпунктов. Например, Вы желаете создать на сайте раздел статей. Для этого в меню добавляется пункт "Статьи", при нажатии на который совершается переход к странице со списком этих статей. Вы скажете, что это уже не совсем меню, но задача отображения пунктов напрямую связана с задачей написания странички, где выводится список подпунктов. Почему? Очень просто, ведь эту страничку вовсе необязательно оформлять именно страничкой. Т.е. при нажатии на ссылку "Статьи" происходит отображение списка статей сразу под этой ссылкой, иными словами, меню получается вложенным. Надеюсь, что такое объяснение более-менее понятно. А если нет - не беда, так как главное - реализовать само меню. Принцип реализации, как я уже сказал, очень простой. Если Вы работаете с базой данных, то заводится отдельная таблица, куда записывается список пунктов. Из программного кода Вы обращаетесь к базе и читаете из таблицы все ее содержимое. Сразу возникает вопрос: что мы собственно получим? А получим мы список слов безо всяких ссылок, разве ж это меню? Поэтому наряду с названиями пунктов в таблице надо хранить некоторое латиское буквосочетание (алиас), по которому произойдет генерация ссылки. Например, если алиас первого пункта задан словом "item1", то ссылка на пункт может быть однозначно сформирована, как "http://somedomain.ru/item1.php". Ниже нарисована логическая таблица для хранения меню.

ID	Название пункта меню	Алиас
1	Об авторе	about
2	Гостевая книга	guest

Ну, а если речь идет о вложенном меню с подпунктами, то надо завести еще одну таблицу, которая реализуется логически так:

ID	Название подпункта	Алиас родительского пункта
1	Какой-то вложенный раздел 1	about
2	Какой-то вложенный раздел 2	about

Иными словами, можно составить этакое древовидное меню, хотя сильную вложенность использовать не рекомендуется. Дело не только в удобстве пользователя, но также в том, что описанная схема будет работать достаточно медленно, особенно, если таблиц подпунктов (таблиц вложенности) окажется не 2, не 3, а, скажем, 10. Есть алгоритмы, которые позволяют создать древовидное меню гораздо эффективнее, но их мы касаться не будем. Вряд ли оно Вам пригодится, а если суровая действительнось заставит сделать что-то подобное, то алгоритмы Вы без труда найдете сами.

Если же Вы работаете с текстовыми файлами, то быстродействие будет на несколько порядков ниже, а структура хранения еще запутанней. А зачем нам запутанный файл на таком простом этапе, как построение меню? Ведь дальше будет гораздо сложнее. Однако, если использования файлов избежать не удается, то схема записи туда меню не будет кардинально отличаться от таболичной. Т.е. у Вас есть некоторый файл, куда записываются пункты меню. Каждый пункт на новой строчке в таком формате "ID|Название|Алиас", где символ "|" является сепаратным, т.е. однозначно отделяющим одно от другого - это необходимо при обработке таких файлов. Для реализации вложенного меню можно долго и упорно "извращаться", если хотите - можете рискнуть, будет Вам первая затейливая задачка.

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

Система статей. На первый взгляд задумка сложная и трудная, но чуть разобравшись становится понятно, что сложность этой задачи во многом иллюзорна. Опять же мы имеем некоторую таблицу с названием, скажем, articles, в которой хранится все, что нам нужно знать о статье. Именно: "ID | Название | Автор | ..всякая_дополнительная_информация.. | Алиас | Категория". Об алиасе мы уже беседовали - это уникальный идентификатор нашей статьи, который является своеобразным ключом ко всей остальной информации. Т.е., зная алиас статьи, мы можем точно назвать ее автора и все прочее, что есть о данной статье в таблице. Другое поле "Категория". Если Ваши статьи строго разделены по тематическим блокам, вроде "О Windows", "Мои рассказы" и проч., то надо уметь определять, к какому именно блоку данная статья принадлежит. В дальнейшем, используя эту информацию, мы сможем организовать много всего полезного, но это уже дело Вашей практики.

Система комментариев. Здесь надо четко понимать один факт: для статей и для новостей комментарии надо хранить в разных местах (т.е. в разных таблицах). Это позволит избежать всякого рода непредсказуемых ситуаций, которые Вы, я уверен, можете сами смоделировать. Например, если нечаяно алиас статьи совпадет с алиасом новости, то как поведет себя система комментариев? Вы ведь уже догадались, что каждый комментарий должен также иметь поле "Алиас", но этот алиас будет принадлежать не комментарию, а статье или новости, для которой он был написан. Свой алиас комментарию иметь совершенно ни к чему, да и трудновато это: генерировать алиас для каждого комментария, возникающего без Вашего ведома, ведь комментарий пишется пользователем.

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

Надеюсь, что идея организации тривиального движка Вам ясна. Конечно, возникнет куча проблем и ощущение непаханного поля, как только Вы возьметесь за реализацию. Но последовательно разрешая все более сложные проблемы, Вы в скором времени получите ту основу, которую уже просто не захочется бросать. Затем эту основу нужно будет "отшлифовать", добавив всякого рода защитные механизмы и Ваш движок будет готов. Помните, что ни в коем случае нельзя обращаться к уже написанным модулям, если Вы хотя бы гипотетически не можете реализовать их сами. Может эта мысль и не совсем оригинальна, но я думаю, что только в процессе изобретения велосипеда можно познать все тонкости программистского ремесла да так, что потом уже ничто не покажется страшным.
---
| Наверх | К началу статьи |

Вот и все! Буду очень рад услышать ваши мнения относительно этой небольшой рассылки. Пишите мне по адресу dagger@dezigner.ru, и всего наилучшего!

Автор статей и ведущий рассылки: Dagger (Сляднев Сергей)

dagger@dezigner.ru