Предыдущие серии
2 Yii, создаем свою CMS. База данных
Наверное в каждом веб-приложении возникает задача разделения, так называемой клиентской или public части — та часть веб-сайта или веб-приложения с которой работает пользователь и админ или back части — часть сайта, с которой работают администраторы, контент-менеджеры и прочие пользователи, отвечающие за наполнение сайта. Сегодня я хочу поговорить о том как это сделать, при использовании фреймворка Yii и какой способ выбрал я при разработке Юпи!.
Критериями для выбора способа будут являться следующие:
- простота реализации
- необходимость выполнять дополнительные «тело движения» (править .htaccess, колдовать с роутингом и т.д.)
И так…
При использовании Yii можно поступить несколькими способами:
- Создать контроллер Admin или Back и всю логику админки реализовывать там;
- В каталоге Controllers создать подкаталог admin или back и все контроллеры и экшены для админки располагать там;
- Админка в виде отдельного модуля Yii;
- Создать два приложения — одно для админской части, другое для клиентской;
Все четыре способа упорядочены по сложности их реализации и по необходимости выполнять дополнительные действия — т.е. писать код!
Кратко рассмотрим достоинства и недостатки каждого из них.
1 Создать контроллер Admin или Back и всю логику админки реализовывать там — наверное самый простой способ.
Достоинтва:
- простота реализации;
- модели используются всем приложением;
Недостатки:
- если админка будет очень большая (с большим функционалом), наш контроллер «раздуется» до огромных размеров, что затруднит сопровождение проекта (эту проблему, отчасти может решить вынесение экшенов в отдельные классы);
- нет отделения админки от остальных частей проекта;
2 В каталоге Controllers создать подкаталог admin или back и все контроллеры и экшены для админки располагать там — второй по сложности реализации способ, забегая вперед, скажу, что я выбрал именно его.
Достоинства:
- админка физически (на уровне каталога файловой системы) отделена от остальных частей проекта, причем это отделение касается не только каталога Controllers, но и каталога View;
- модели используются всем приложением;
Недостатки:
я пока их не нашел 🙂
3 Админка в виде отдельного модуля Yii — по правде говоря, кода я начал разрабатывать Юпи! и столкнулся с проблемой разделения на back и front части — тогда еще не было поддержки модулей в Yii (она появилась в версии 1.0.3), поэтому данный способ я не рассматривал. Если кто-то пытался поступить таким образом — прошу рассказать о своем опыте в комментариях.
4 Создать два приложения — одно для админской части, другое для клиентской — как мне кажется, самый трудоемкий способ.
Достоинства они же, от части, являются и недостатками:
- части системы полностью изолированы друг от друга, из этого следует что без «пляски с бубнами» и дополнительных опций в конфиге не получится использовать модели и библиотеки одного приложения в другом, а отсюда вытекает дублирование кода и все что с ним связано.
Для себя я выбрал способ №2, он, как мне кажется, наиболее удовлетворяет всем моим требованиям.
Таким образом мы имеем следующую структуру проекта.
Вопрос разделения приложения на 2 части поднимался на официальном форуме Yii, почитать можно тут.
Кроме такого вот разделения приложения на две части, для каждой из них я сделал свой базовый контроллер, таким образом все контроллеры клиентской части наследуются от YFrontMainController, а контроллеры админской части от YBackMainController. Введение новых базовых контроллеров позволяет:
- реализовать функционал, специфичный для каждой части приложения, в одном месте, что облегчает повторное использование и сопровождение;
- как правило, для клиентской и адмиской частей используются разные лайауты (layouts), разделение контроллеров позволяет реализовать это очень просто (для этого достаточно переопределить свойство layout);
Например, для всех контроллеров админки, я применяю фильтр, проверяющий авторизацию пользователя, не имея базового контроллера, мне бы пришлось прописывать его во всех контроллерах админки. Так же применяется xss-фильтр, для всех данных, отправляемых из панели администрирования.
Скорее всего, выбранное мной решение, не является идеальным и имеет скрытые (пока!) от меня недостатки, если Вы о таковых знаете — прошу высказываться в комментариях.
Удачного yii-кодинга, друзья!
Основной сайт Юпи! — http://yupe.ru
Исходный код — https://github.com/yupe/yupe
Присоединяйтесь!
Привет!
Погружаешься в разработку ? Ищешь ментора ?
Поделюсь своими знаниями и опытом - https://opeykin.ru/mentor/
Думаю вариант 3
Давно пора сразу думать о более гибкой архитектуре — SaaS!
Купили сайт, делать ничего не хотят, админка удалённая, просто подконектился и управляешь(за саппорт гребёшь бабло), а все контролери и вьюхи екстендятся издалека (могут например загружатся тарчиком во временную директори, на момент работы), или из модуля…
На самом сайте только то, что нужно для его работы, не более!
ps: тут много тем для разговора можно поднять 😉
Конечно такой вариант возможен! Но, по моему мнению, он подходит для «больших» и «Масштабных» CMS-ок, а для блога — это будет излишеством (если конечно не планируется создавать 10-15 блогов и управлять ими из одной панели) ИМХО конечно!
Так ты блог создаеш или CMS? чета непонятно =)
Вообще блог! Но может все перерастет в простенькую ЦМС-ку )))
Я пробовал отдельное приложение. На самом деле, все не так страшно как вы пишете 🙂 Копируется конфиг фронтенда (фактически, нужен только доступ к базе и настройки юзера + что сами используете), если используете перезапись урлов — то правите хтаксес и наслаждаетесь — все модели, контроллеры и т.п. доступны, потому что новое приложение — это всего лишь новая точка входа. Я описывал вот здесь как сделать: http://www.yiiframework.com/forum/index.php/topic,924.msg12171.html#msg12171
Вот нашёл тут CMS-ку со схожем названием:
http://yupi-cms.com/
Вот блин….просмотрел…может придумать другое название или все-таки оставить??
Yupe! != Yupi !!!
Думаю можно попробывать придумать другое.
А лучше — выставить это на голосование.