Comments 52
Статьи по Yii интересны, давно руки тянутся к этому фреймворку. И еще. Use
<source lang="php"></source>Luke
Спасибо за статью, познавательно. Не подскажите как настроить urlmanager для административной части, чтобы ссылки выглядели например так:
localhost/yourapp/post/admin/
localhost/yourapp/post/admin/
Можно например в htaccess сделать
а дальше в protected/config/backend.php:
RewriteRule ^admin admin.php
а дальше в protected/config/backend.php:
'urlManager'=>array(
'urlFormat'=>'path',
'showScriptName'=>false,
'rules'=>array(
'admin'=>'admin/index',
'admin/<_c>'=>'<_c>',
'admin/<_c>/<_a>'=>'<_c>/<_a>',
),
),
Если yourapp — это контроллер, post — действие, а admin просто для красоты, то правило будет выглядеть так:
Это для случая, когда контроллеры админки лежат в поддиректории, как я описал ниже.
'/<controller>/<action>/admin'=>'admin/<controller>/<action>',Это для случая, когда контроллеры админки лежат в поддиректории, как я описал ниже.
Разные базовые классы для фронт- и бэкэнда это правильно. У меня в них еще живут пара полезных методов loadOr404 (если модели с нужным id не нашлось, то 404) и flashAndRedirect (ставим flash сообщение и редиректим).
А вот рисовать дополнительный behavior не обязательно. Можно без него все разделить. Контроллеры админки (у меня cp, от control panel) кладутся в поддиректорию /controllers/cp/ а контроллеры фронтэнда в корень, т.е. просто в /controllers/. Также и с views. Route, в терминах yii, к админке выглядит так
Теперь все запросы приходят на общий index.php. Если необходимо разделить конфиги — если у админки много обвеса и правил для маршрутизации, то мысль здравая — можно во входном скрипте по первому сегменту url определять нужный конфиг.
Я вот еще подумываю у моделей разделить подключаемые поведения на «для админки» и «для фронтэнда», ибо для фронтэнда их надо на порядок меньше, а объекты поведений создаются и инициализируются сразу все, без ленивой загрузки.
А вот рисовать дополнительный behavior не обязательно. Можно без него все разделить. Контроллеры админки (у меня cp, от control panel) кладутся в поддиректорию /controllers/cp/ а контроллеры фронтэнда в корень, т.е. просто в /controllers/. Также и с views. Route, в терминах yii, к админке выглядит так
array('cp/controller/action');, что наглядно. Да и в пути к фронтэнду лишних директорий нет.Теперь все запросы приходят на общий index.php. Если необходимо разделить конфиги — если у админки много обвеса и правил для маршрутизации, то мысль здравая — можно во входном скрипте по первому сегменту url определять нужный конфиг.
Я вот еще подумываю у моделей разделить подключаемые поведения на «для админки» и «для фронтэнда», ибо для фронтэнда их надо на порядок меньше, а объекты поведений создаются и инициализируются сразу все, без ленивой загрузки.
А чем не подошло решение сделать админскую часть отдельным модулем? На мой взгляд более гибко и удобно. Все в одном месте, у Вас же все будет раскидано по куче папок в корне (views, components и т.д.).
Можно админку вынести на поддомен и сделать в index.php так:
if(($sd = explode('.',$_SERVER['HTTP_HOST'])) && $sd[0] == 'admin')
Yii::createWebApplication('./protected/config/admin.php')->runEnd('admin');
else
Yii::createWebApplication('./protected/config/www.php')->runEnd('www');
Подход интересный, но он может иметь место если вы не используете сторонние модули в своих проектах. Отказ от огромной базы расширений Yii, имеющих собственный backend все же — не самый верный шаг.
Хотя, если вы знаете универсальный путь, как подружить такой подход с 3rd party extensions — мне было бы очень интересно почитать.
Хотя, если вы знаете универсальный путь, как подружить такой подход с 3rd party extensions — мне было бы очень интересно почитать.
Вообще-то именно для этого в Yii существуют модули, вариант с выделением backend в отдельный модуль кажется мне более логичным.
Тоже раньше использовал отдельный модуль, но часто неудобно бывает использовать внешние модели и компоненты.
Модуль подразумевает использование собственных моделей, а ведь они и фронтэнду пригодятся.
вот вот
Модели, разделяемые бэкэндом и фронтэндом должны лежать на фронтэнде.
А вот как кршерно сделать такое: админка выделена в отдельный модуль, модели пользует от фронтэнда, но вот контроллеры нужно сделать так, чтобы админский контроллер наследовал фронтэндский. Как это сделать правильно в yii (ибо часть функционала контроллеров совпадает)? Не очень могу понять пока, как это правильно сделать
к тому же, оф. сайт использует схожу структуру, соотв. разработчики фреймворка продпочитают этот подход модулям прочитать можно здесь
А вот это интересно, за ссылку спасибо
По Вашей ссылке другая структура. Несколько отдельных приложений (frontend, backend, console), которые используют общие библиотеки (models и т.д.), которые лежат в common.
Автор топика другой вариант предлагает.
Автор топика другой вариант предлагает.
Интересная заметка, спасибо за ссылку. Я так понял модули там не используются, только разбиение по директориям, так?
Соглашаюсь и поддерживаю
(придираюсь) это не фронт/бек—END, а фронт/бек—OFFICE. ENDы — более технические, в то время как OFFICEы — более человеческие. Nginx — техническое, Админка — человеческое :)
Этому подходу уже год )
я как раз столько им пользуюсь, отличный метод.
я как раз столько им пользуюсь, отличный метод.
Статья супер. Советы очень помогли.
С почином, в стане Yiiводов прибыло.
А как при таком разбиении ведет себя Gii? Пользуетесь ним?
Я пока что использую админку в качестве модуля.
Я пока что использую админку в качестве модуля.
ведет себя отлично, localhost/index.php/gii или localhost/admin.php/gii велкам
а смысл в бекенде вообще? почему бы не держать управление неким компонентом в контроллере/модуле этого компонента. Я вообще пытаюсь максимум управления выносить в само приложение
ну например часто заказчики просят отделять управление от самого сайта
заказчики часто хотят чегото непонятного. им наверное льстит что у них есть доступ к папочке, куда больше никто не имеет доступ :) я вот не вижу ни одного плюса такого разделнния. Даже редактирование страници можно организовать на самой странице, спасибо contenteditable, и не надо перелогиниваться/переходить в какието бекоффисы. к томуже тогда компонент будет не размазан по всей системе а в идеале лежать в одной папочке.
Отличный перевод,
приятно видеть свой код в статьях хабра :)
приятно видеть свой код в статьях хабра :)
Спасибо автору за статью.
Подскажите пожалуйста один вопросик. Сделал структуру приложения как в статье, однако при заходе localhost/youapp/ мне выбрасывает сообщение.
Очевидно бтблиотека не может найти controller site, поскольку в config/main.php указано
Ок, добавил контроллер site в директорию front и изменил вышеупомянутый конфиг так:
Все работает однако получается, что для backenda нужно сделать тоже самое?
Можно ли как-нибудь для обработок ошибок (ну и возможно для других настроек) все-таки использовать дефалтовый контроллер site?
Подскажите пожалуйста один вопросик. Сделал структуру приложения как в статье, однако при заходе localhost/youapp/ мне выбрасывает сообщение.
Unable to resolve the request "site/error".
Очевидно бтблиотека не может найти controller site, поскольку в config/main.php указано
'errorHandler'=>array(
// use 'site/error' action to display errors
'errorAction'=>'site/error',
),
Ок, добавил контроллер site в директорию front и изменил вышеупомянутый конфиг так:
'errorHandler'=>array(
// use 'site/error' action to display errors
'errorAction'=>'front/error',
),
Все работает однако получается, что для backenda нужно сделать тоже самое?
Можно ли как-нибудь для обработок ошибок (ну и возможно для других настроек) все-таки использовать дефалтовый контроллер site?
При необходимости разделить на frontend/backend компоненты можно сделать так:
/components
---/backend
---/frontend
---/common
Импорт в конфиге main.php
Импорт в конфиге backend.php
Импорт в конфиге frontend.php
/components
---/backend
---/frontend
---/common
Импорт в конфиге main.php
'application.components.common.*',Импорт в конфиге backend.php
'application.components.backend.*',Импорт в конфиге frontend.php
'application.components.frontend.*',Sign up to leave a comment.
Способ разделения frontend/backend-частей в Yii