Главное -- понимать, что идеальных решений не бывает. И любая универсальная CMS уступает специально разработанному приложению для решения конкретной задачи. По крайней мере при решении основного ТЗ проекта.
Приложение, решающее конкретное ТЗ должно все равно писаться из расчета необходимости расширения в будущем. Вот тут и получается, что все равно пишется приложение так как буд-то это узко направленная CMS.
Тут стоит отметить, что я понимаю под аббревиатурой CMS.
CMS -- это веб-приложение способное решать широкий круг задач, являющееся модульным решением, имеющее набор API функций позволяющий безболезненно расширять функционал системы без вмешательства в основной код системы.
Т.е. CMS не может иметь жестко фиксированный функционал, когда расширение требует вмешательства в уже написанный код.Если отталкиваться от такого подхода, то становиться очевидным, что изначально при разработке следует предусмотреть чуть ли ни все случаи жизни. Но в конечном счете, все предусмотреть невозможно и вот тогда появляются обновления для ядра.
Итак основные вопросы которые, как мне кажется, следует решить перед тем как начинать разработку своей CMS:
- Если нужна мультиязычность в системе, то о её поддержке следует позаботиться еще в ядре.
- Определить КАК будет вызываться ваш backend (админка).
- Какими данными будет оперировать система?
Будут ли разрешены GET-запросы. Поддержку можно оставить, но стараться их избегать. - Кеширование.
Этим, на мой взгляд, должно заниматься ядро. - Роутинг.
Думаю тут все понятно. Ядро разбирает URL и принимает решение куда передавать управление. - Построение строк URL.
Это важный момент. Все URL должны строиться по неким правилам. - Как будут взаимодействовать между собой модули.
- Как будут происходить AJAX-запросы.
- Хранение параметров системы -- ядра и модулей в частности.
- Стоит ли писать всю систему с нуля или взять за основу фреймверк.
- Возможность для модулей управлять процессом загрузки системы.
Своеобразный bootstrap или ловушки. - Взаимодействие с Базой Данных.
ORM -- уровень абстракции. - Набор стандартных функций и классов для часто используемых операций с данными.
- Как система будет работать на хостинге.
Для каждого сайта отдельная копия ядра или же ядро (и модули)будет цепляться из основного репозитария симлинками или другими способами.
Теперь, расскажу подробнее про некоторые из них.
Языки.
Совершенно не обязательно риализовывать всю поддержку именно в ядре. Я бы даже сказал, это нельзя делать в ядре. В ядре Вы можете определить (например) первый сегмент строки адреса (или некую переменную GET) и описать вызов модуля обработки языков если таковой имеется, именно он уже должен выполнить все что нужно.
С другой стороны, данная задача может решать и без участия ядра -- через ловушки ядра о которых будет сказано ниже.
Backend.
Это может быть специфический сегмент строки адреса. Очень не рекомендую использовать стандартные названия вроде admin или administrator -- зачем пользователям знать по какому адресу расположена Ваша админка? Но и без фанатизма, строку вроде 3jf3mrjk5 тоже делать не стоит, думаю понятно почему.
Кеширование.
Очень хорошо если будет возможность использовать несколько уровней кеширования. Или же несколько видов кеширования -- например, файловый кеш и memcached. Если вы предоставляете выбор типа кеширования, то модуля системы не должны зависеть от выбранного типа -- API кеширования должна быть стандартной и работать для любого типа кеша.
URL.
Нужна возможность безболезненно перестроить URL конертного типа документов без опасности, что в каком-то из шаблонов забыли поменять строчку.
Взаимодействие между модулями.
Грубейшей ошибкой будет устанавливать жесткую связь между модулями по их именам. Исключения -- модуль языков и пользовательской авторизации. Эти модуля могут быть фиксированными, но тот же модуль языков может и отсутствовать, если сайт не требует мультиязычности.
AJAX.
Это может быть отдельным мини-ядром. Сами AJAX запросы, подразумевают в большинстве случаев очень конкретные запросы, когда не нужно загружать кучу расширений, а нужно выполнить лишь конкретный вызов с конкретными параметрами.
Параметры.
Очень не помешает единый стандарт хранения параметров. Ядро может иметь специализированный класс для загрузки и сохранения конфигов как ядра так и модулей в отдельности.
Есть вариант хранение всех параметров в дином хранилище... Что ж, это конечно вариант. Можно сказать, даже заманчивый. Но имеет свои минусы. Например -- быстрое развертывание модуля и удаление. При развертывании, при наличии удачно настроенного модуля на другом сайте, можно перенести его с его отдельными конфигами на другой сайт и тут же запустить его в работу, а при удалении безболезненно избавиться от всех его следов. Конечно, это возможно и с централизованным хранилищем, но более хлопотно.
Основа -- с нуля или фреймверк.
Тут за Вас никто не решит. Правильного решения не существует. Но фреймверки придуманы для ускорения разработки. Они задают стиль приложения, дают кучу полезных библиотек которые уже отлажено работают вместе и фреймверк обычно берет на себя многие вопросы жизненного цикла приложения. Выбор Какой фреймверк использовать? это тоже вопрос имеющий множество ответов. Кому-то нравиться ZF, кто-то считает венцом творения Kohana или CakePHP. Я в свое время начал с CodeIgniter и считаю его достойным выбором. Хотя за все это время нашел массу слабых мест в нем и активно присматриваюсь к другим фреймверкам.
Bootstrap.
Тут вопрос происходит от предыдущего -- основы системы. Если Вы пишете все с нуля, тогда у Вас есть возможность организовать наиболее гибкую механику загрузки системы. Фреймверки обычно тоже дают некоторую степень свободы.
Необходимость управлять загрузкой системы возникает когда требуется изменить ход работы ядра. Например, можно его расширить, добавив к нему некоторый функционал или изменить существующий. Другой случай -- Вам нужно обрабатывать всю страницу, после того как она будет полностью сформирована, но до того как она будет отправлена пользователю или помещена в кеш.
База данных.
Очень большим плюсом будет возможность системы работать на разных базах данных -- MySQL, Postgres или других. В данном случае, очень хорошо помогают фреймверки, т.к. очень часто, они имеют в себе ORM. Но есть очень много различных самостоятельных решений и для случая разработки с нуля.
Стандартные наборы.
Это могут быть функции или классы для обработки ассоциативных массивов, построения элементов форм или других html-объектов, функции работы со строками... В общем, то что может понадобиться большинству модулей.
Работа на хостинге.
В случае веб студии, вероятнее всего будет лучше, если все сайты производимые студией и размещаемые на одном хостинге будут использовать одну и туже копию ядра и модулей. Это решает множество проблем поддержки, например проблему Устаревшей системы, когда через пол-года, год владелец сайта попросит что-то доработать, а система у сайта безнадежна устарела. При этом постоянно обновлять несколько десятков или даже сотен сайтов в ручную -- абсолютно дурная работа. Да, с этим может справиться некий скрипт автоматизации или механизм автообновления системы из внешнего репозитария. Но об обновлениях я скажу позже -- эта тема достойна отдельной статьи.
Все вышесказанное относиться непосредственно к ядру. Т.е. к основе системы. Скорее всего я что-то упустил, но основное все же перечислил.
Комментариев нет:
Отправить комментарий