Столько веселых ребят И каждый делает велосипед. И один из них однажды утром Он достанет порох.
Виктор Цой.
Сначала я хотел написать статью в раздел «Я пиарюсь» о том, какой я молодец и какое замечательное дело я сделал, но немного покопавшись в Интернете, с удивлением обнаружил, что я совсем не такой.
единственный в своем роде.
Тогда я решил пойти от обратного: наверное, почти каждый веб-программист хотя бы раз в жизни пытается написать полноценную CMS. При этом в процессе проектирования (а этот процесс часто начинается уже во время написания кода) у разработчика наверняка возникнут вопросы.
С этими вопросами он обращается к поисковикам и попадает на сайты тех, кто уже проходил подобные грабли.
Итак, я начал смотреть, с какими запросами ко мне приходят начинающие «велоразработчики», и постарался выделить некоторые вещи, которые не были для меня очевидны в начале работы.
1. MVC — наше всё!
Везде, где заходит разговор о разработке веб-приложений, сразу всплывает модная аббревиатура MVC (Модель-Представление-Контроллер).Этот подход утверждает, что интерфейс должен быть отделен от логики, а логика от данных.
Не скажу, что меня полностью вдохновили эти идеи, но я готов с пеной у рта защищать, что изменения в дизайне (или даже дизайне) не должны влиять на логику кода :) Вот здесь и кроются грабли номер один: внешний вид должен быть отделен от логики программы.
Как это сделать – каждый решает сам.
По этому вопросу сломано немало копий: есть различные шаблонизаторы, xslt-преобразования и просто php+html, вынесенные в отдельные файлы.
Выбор большой, но «серебряной пули», как обычно, нет: на одной чаше весов лежит гибкость, на другой — ясность.
Даже Умник , с его «программированием для самых маленьких» многим пользователям кажется сложным.
Так что если мы ориентируемся на пользователя, желающего установить систему «из коробки» и адаптировать ее под свои нужды с минимальными знаниями программирования, то стоит поломать голову.
Кроме того, конструкции должны быть заменяемыми и возможно даже на лету.
То есть нужно предусмотреть удобное их хранение и редактирование.
И еще один момент, который многие игнорируют: дизайн должен легко редактироваться и обновляться.
Если вам пришлось адаптировать дизайн какого-нибудь бесплатного форума, состоящего из двухсот шаблонов, в котором все намертво забито таблицами и куски JavaScript вставлены откуда-то «не по логике», то вы понимаете, что именно вы делаете не хочу видеть.
Я придумал такой дизайн: пользовательский дизайн содержит только то, чего нет в базовом дизайне.
То есть в самом минималистичном случае дизайн представляет собой пустую директорию с названием дизайна.
Понятно, что в этом случае конструкция будет выглядеть точно так же, как базовая, поскольку все недостающие детали будут позаимствованы из нее, но как отправная точка это очень удобно.
Если в дизайне появляется css, система автоматически на него переключается (при этом html все равно заимствует из базового).
То же самое и с JS. Что мы из этого получаем: дизайн пользователя содержит только те файлы, которые он сам сделал.
Пользователю не нужно помнить, какой файл он исправил, а какой просто скопировал из базового дизайна в начале своей работы.
Также на сайте отображаются практически все нововведения в базовом дизайне без редактирования кастомного.
Мне эта система показалась удобной и логичной, хотя некоторым она кажется несколько неожиданной.
Принимать его или придумать свой – решать вам.
2. Структура сайта
Приступим к написанию ядра.Что должно делать ядро? И он должен делать всю «грязную» работу: определять настройки сайта, права и настройки групп пользователей, используемых модулей, шаблонов, параметров кэширования, локализации и т. д. То есть, чтобы к моменту начала работы плагинов они могут получать всю интересующую их информацию из ядра.
Звучит жутковато, но все это сравнительно легко написать и работает, если четко понимать взаимодействие элементов.
Я для себя решил, что сайт будет не кучей страниц, сваленных куда-то в базу данных, а строгой иерархией.
В результате структура сайта древовидная и недостающие части, как и в случае с дизайнами, наследуются от родителей.
Структура групп пользователей также древовидная — права и настройки также наследуются от родителей.
Файлы и модули локализации также имеют простую иерархию.
Четкая иерархия позволила перенести на движок всякие неприятные вещи, такие как автоматическая генерация карты сайта, различные меню, распределение прав (да, дать право на что-то нескольким группам - это совсем не так).
необходимо редактировать каждый - достаточно определить иерархию) и т. д. Живите и радуйтесь! И всё было бы хорошо, если бы не грабли:
Первые грабли.
Кэширование.
Пока я проектировал свой «мегадвигатель», мне как-то было не до кеширования.
И подумайте, что в этом такого сложного? Я поместил страницу в переменную, сохранил в файл и в следующий раз показал оттуда.
Бизнес.
вы можете добавить его в любой момент! Ох… а у нас есть еще одна страница для зарегистрированных пользователей… Хм… ну, подумаешь – две страницы сохраним в кэше! А в шапке нужно вывести «привет, Вася»… ну значит этот фрагмент не должен кешироваться в шапке.
и в подвале один и тот же фрагмент. и посередине.
Хм.
Еще хотелось бы закешировать разные части страницы на разные периоды.
Садимся и переписываем движок и систему кеширования на кеширование в блоках — чтобы каждый блок имел свое время жизни.
Вторая рейка.
Кэширование.
Как?! Опять кэширование? Все уже сделано красиво! Ну да.
делали.
и это даже работало, пока не встала задача генерировать контент для каждого пользователя на основе его личных настроек.
При этом размер кэша растет со скоростью истребителя, а его содержимое устаревает гораздо раньше, чем будет запрошено вновь.
Вместо ускорения сайта мы получаем его замедление, а гигабайты кешированных страниц никому не нужны.
Главным скриптом на сайте становится «Его Величество» инвалидатор кеша.
Хммм.
давайте еще раз перепишем движок: на этот раз мы реализуем кеширование на уровне запросов к базе данных, поскольку это самое большое узкое место в производительности.
Переписал.
всё - нирвана.
Третьи грабли.
Кэширование.
Смотришь на свое творение и чувствуешь себя полным идиотом: вместо того, чтобы сохранять всю страницу, я каждый раз ее создаю.
Но кэширование было создано для достижения прямо противоположного результата! Как я так облажался? Конечным результатом стало то, что некоторые модули кэшируются блоками, а некоторые — на уровне запроса.
Это позволяло месяцами хранить в кеше такие редко меняющиеся вещи, как, например, меню сайта.
Урок, который я усвоил для себя, таков: система изначально должна быть спроектирована таким образом, чтобы на определенных этапах исполнения в ней были сгруппированы данные, которые можно было бы легко кэшировать или брать оттуда.
Также система кеширования не должна быть жестко привязана к движку, так как сегодня достаточно хранить кеш в файлах, а завтра (или даже сегодня вечером) можно начать работу с сервером memcache. 
В процессе написания движка также имеет смысл прочитать умную книгу о рефакторинге.
или прочитать ее после написания движка.
В любом случае от этого могут выиграть все трое (вы, движок и книга).
3. Модульность.
Трудно представить современную систему как «вещь в себе» — она должна иметь интерфейсы для расширения своего функционала.
Итак, переходим к самой вкусной части CMS — написанию модулей.
Здесь тоже возникает много вопросов: как должен выглядеть модуль, как подключиться к системе и т.д. В некоторых системах вызовы модулей жестко запрограммированы в ядре системы, поэтому если вы хотите написать модуль или установить сторонний, то зайдите в исходники, вооружитесь инструкцией по установке и впишите в код соответствующие вызовы.
.
Несмотря на идиотизм подхода, многие системы функционируют именно так.
Есть вариант этого решения: каждый модуль представляет собой отдельный файл в определенном каталоге.
В этом случае нам придется не только записать модуль в ядро, но и выполнить его в виде одного файла.
Были и варианты с активными шаблонами: то есть вводили в шаблон {имя_модуля} и когда парсер доходил до этого тега, вызывался на исполнение модуль имя_модуля, результат которого оказывался на месте тега.
Возможно, такой способ удобен, но в данном случае мы не только не отделили логику от представления, а даже наоборот — тщательно их перемешали.
После определенного количества ударов я пришел к системе, которая, возможно, и не является примером лаконичности и простоты, но мне видится вполне удобной.
Каждый модуль представляет собой отдельный каталог, из которого ядро вызывает только один файл (index.php).
Этот файл может одновременно отображать «Hello world!» и включить файлы управления квазиизлучателем гиперпространства - это будет удобно разработчику модуля.
В этой же директории находится xml-файл с описанием параметров модуля, возможных настроек и системы прав.
Этот файл используется для того, чтобы система могла сама добавлять модули и не перекладывать эту головную боль на пользователя: нажмите кнопку «установить модуль» — пожалуйста, получите.
С установкой разобрались.
Возникает новая проблема — как запретить пользователю размещать, скажем, фотоальбом и, например, форум на одной странице? На здравый смысл полагаться бесполезно, поэтому необходима типизация модуля.
Модуль такого типа (где-то я видел понятие «компонент» для таких модулей) может иметь на странице только один.
Ну да ладно, компонент на странице будет только один, а других может быть много — в каком порядке их подключать? Ведь было бы глупо, если бы модуль какого-нибудь скин-свичера, который в конце своей работы перенаправляет пользователя на главную страницу сайта, подключается после того, как модуль анализа динамики поголовья кроликов в брачный период сработает. сработало — и результатов анализа мы не увидим, и потратим время на расчеты.
Поэтому модули должны иметь определенный порядок их подключения.
Некоторые для этого вводят аналог уровня запуска niks, где для каждого модуля нужно прописать, между какими модулями он должен подключаться.
Как пользователя это решение повергло меня в прострацию, но как разработчика я придумал почти то же самое: модули разделены на три большие группы.
Одна из групп представляет собой уже упомянутый «компонент», две другие отличаются лишь тем, что модули одной группы подключаются до компонента, а другой – после.
Причем это разделение я скрыл от пользователя, чтобы для него остались только «компонент» и «просто модуль».
Итак, модуль спроектирован, подключение решено.
Теперь нужно решить, как его настроить и как получить к нему доступ.
А тут все просто: раз наше ядро рассчитано на «грязную» работу, то пусть у него болит голова — модуль в xml выдал список настроек, а ядро его разобрал, сохранил и предоставил по запросу — вот и все.
все Просто.
Еще одной проблемой, с которой я столкнулся в процессе разработки, была передача данных между модулями.
По условиям задачи они ничего друг о друге не знают и вызываются ядром в порядке номеров.
Но я хочу перенести новости из одного модуля в другой! Для этого я ввел специальный класс для глобальных переменных, где каждый модуль может что-то сохранять на память для тех, кто придет после него.
Возможно, это не очень элегантное решение.
4. Обновления
Всегда хочется иметь самую свежую версию, но делать это с минимумом телодвижений.Отсюда и желание автоматизировать процесс обновления.
И здесь снова пусть и не очень обширный, но все же зоопарк решений.
Самые прогрессивные предлагают установить права 777 для всех каталогов и 666 для файлов, и тогда «скрипт все сделает сам».
Тот факт, что это дыра в безопасности размером с Гранд-Каньон, никого не волнует. У меня были идеи двух вариантов: скрипт скачивает обновления во временный каталог, а затем, запросив у пользователя параметры доступа по FTP, обновляется сам.
Так что не нужно давать ему никаких дополнительных прав, и все происходит автоматически, и обновления гоняются внутри сервера.
остается либо каждый раз запрашивать у пользователя параметры доступа по FTP, либо хранить их тут же на сервере.
сайт. то есть все яйца в одну корзину.
Поэтому я предпочел другой вариант: пользователь сам скачивает обновления (в архиве или через svn), загружает их на сайт, а код на сайте, почувствовав, что он стал «новее», вносит необходимые исправления в базу данных и /или настройки.
Но первый вариант всё же был красивее.
но я не рискнул.
Это самые запоминающиеся вехи моего «велостроения».
Читая это, я очень сожалею, что в начале своей работы я не сталкивался с чем-то подобным, а у меня самого не было достаточно опыта и больших кадров, чтобы задавать «правильные» вопросы.
В итоге я получил тебя ты можешь посмотреть здесь и если у вас есть вопросы, я готов на них ответить.
Кстати, если у вас есть ответы на незаданные вопросы, я тоже буду рад их выслушать.
Ведь с опытом знаешь чей это сын, и совершить все ошибки в одиночку практически невозможно ;) Теги: #CMS #разработка cms #грабли #шишки #велосипеды #CMS
-
Thunderbird 2 Задерживается
19 Oct, 24 -
От Новичка До Пользователя. Шаг 1
19 Oct, 24 -
Palm Pre Выдает Себя За Apple Iphone
19 Oct, 24 -
Для Чего Создан Сайт-Ловушка?
19 Oct, 24
