Doctrine + CodeIgniter: symfony-style CMS
Вот что пока не сумел сделать - так это присобачить к CI систему, подобную симфоневым плагинам. Поэтому установка чего угодно потребует копипаста.
Но вот что у нас есть в начальной версии админки:
1) Схема данных под Doctrine. Смело и решительно смотрим в схему симфоневого sfGuargPlugin, забираем оттуда пользователей, группы и все таблицы-связки.
А вот разрешения (permissions) будут отличаться. Дело опять-таки в организации фреймворка: вместо привычных глазу отдельных модулей в одном приложении мы имеем мешанину контроллеров, собранную в одном каталоге и все, что можно сделать - это поместить относящиеся к CMS контроллеры в определенный подкаталог, поэтому просто прописать где-то в конфиге, что для доступа к этому модулю нам нужны такие-то разрешения... можно. Однако как это сделать удобно, я пока не придумал. Поэтому поступил по-другому. Но об этом позже
2) Приложения внутри проекта у нас, повторюсь, отсутствуют. При этом любой контроллер фронтенда и бекенда должен при объявлении выполнять набор определенных действий; и эти наборы сильно отличаются. Выход - два разных родительских контроллера, каждый из которых - потомок родного. Родной игнайтеровский class Controller можно переопределить, скажем, в core/MY_Controller. Но только один раз.
Отсюда первое решение напильником и такой-то матерью: заводим core/CMS_Controller, в каждом контроллере-потомке инклюдим его вручную.
3) Дальше все более-менее по классике: у нас есть ряд типовых actions, как то: list, create, edit, delete. От себя добавил еще readonly, т.к. по техническим требованиям к софтине удаление элемента должно происходить только после предварительного просмотра его деталей.
Делается все тоже более или менее по классике: определеяем module & action
$this->module = $this->router->fetch_class();
$this->action = $this->router->fetch_method();
4) В файле конкретного модуля прописываем, с какой таблицей модуль работает, и передаем имя таблицы в конструктор CMS-контроллера, таким образом настраивая его на работу с этой таблицей:
class cmsMain extends CMS_Controller {
сonst TABLE = 'TopBanner';
...
public function __construct() {
...
parent::__construct(self::TABLE, $options, $isSecured);
}
}
Тут стоит обратить внимание на $options, где прописываются настройки, которые в симфони вынесены в moduleName/config/generator.yml
Не слишком удобно, но в целом работает. Наборы столбцов-полей, типы полей, лейблы, столбец и порядок сортировки по умолчанию. Индивидуальные вью для вывода определенных столбцов и полей редактирования. И что-то еще там точно было.
5) Как водится, любой метод можно переопределить, настраивая админку под конкретные нужды.
6) И вот теперь мы возвращаемся к разрешениям. Можно было бы завести очередную опцию, прописывающую требуемые на определенное действие разрешения, но я поступил по-другому, т.к. требовалось сделать некий визуальный интерфейс, который позволит суперадмину назначать разрешения, не залезая в конфиги.
Все достаточно примитивно: разрешение представляет собой название + модуль + набор действий: is_delete, is_list, is_edit и т.д.
Если прописать all в названии модуля и проставить все галочки, получим всесильного суперадмина.
7) Что еще... В автоматическом генераторе интерфейсов все начинается с
$table = Doctrine::getTable($this->table);
$columns = $table->getColumns();
что дает набор полей и их основных характеристик, и далее пляшет от этой печки плюс определенных при создании модуля опций.
***
Ну вот так как-то. Ога, это пока кривовато, зато ставится достаточно легко и настраивается тоже неплохо. Что, впрочем, не исключает необходимости ваять следующую версию, которая учтет косяки предыдущей.
Но вот что у нас есть в начальной версии админки:
1) Схема данных под Doctrine. Смело и решительно смотрим в схему симфоневого sfGuargPlugin, забираем оттуда пользователей, группы и все таблицы-связки.
А вот разрешения (permissions) будут отличаться. Дело опять-таки в организации фреймворка: вместо привычных глазу отдельных модулей в одном приложении мы имеем мешанину контроллеров, собранную в одном каталоге и все, что можно сделать - это поместить относящиеся к CMS контроллеры в определенный подкаталог, поэтому просто прописать где-то в конфиге, что для доступа к этому модулю нам нужны такие-то разрешения... можно. Однако как это сделать удобно, я пока не придумал. Поэтому поступил по-другому. Но об этом позже
2) Приложения внутри проекта у нас, повторюсь, отсутствуют. При этом любой контроллер фронтенда и бекенда должен при объявлении выполнять набор определенных действий; и эти наборы сильно отличаются. Выход - два разных родительских контроллера, каждый из которых - потомок родного. Родной игнайтеровский class Controller можно переопределить, скажем, в core/MY_Controller. Но только один раз.
Отсюда первое решение напильником и такой-то матерью: заводим core/CMS_Controller, в каждом контроллере-потомке инклюдим его вручную.
3) Дальше все более-менее по классике: у нас есть ряд типовых actions, как то: list, create, edit, delete. От себя добавил еще readonly, т.к. по техническим требованиям к софтине удаление элемента должно происходить только после предварительного просмотра его деталей.
Делается все тоже более или менее по классике: определеяем module & action
$this->module = $this->router->fetch_class();
$this->action = $this->router->fetch_method();
4) В файле конкретного модуля прописываем, с какой таблицей модуль работает, и передаем имя таблицы в конструктор CMS-контроллера, таким образом настраивая его на работу с этой таблицей:
class cmsMain extends CMS_Controller {
сonst TABLE = 'TopBanner';
...
public function __construct() {
...
parent::__construct(self::TABLE, $options, $isSecured);
}
}
Тут стоит обратить внимание на $options, где прописываются настройки, которые в симфони вынесены в moduleName/config/generator.yml
Не слишком удобно, но в целом работает. Наборы столбцов-полей, типы полей, лейблы, столбец и порядок сортировки по умолчанию. Индивидуальные вью для вывода определенных столбцов и полей редактирования. И что-то еще там точно было.
5) Как водится, любой метод можно переопределить, настраивая админку под конкретные нужды.
6) И вот теперь мы возвращаемся к разрешениям. Можно было бы завести очередную опцию, прописывающую требуемые на определенное действие разрешения, но я поступил по-другому, т.к. требовалось сделать некий визуальный интерфейс, который позволит суперадмину назначать разрешения, не залезая в конфиги.
Все достаточно примитивно: разрешение представляет собой название + модуль + набор действий: is_delete, is_list, is_edit и т.д.
Если прописать all в названии модуля и проставить все галочки, получим всесильного суперадмина.
7) Что еще... В автоматическом генераторе интерфейсов все начинается с
$table = Doctrine::getTable($this->table);
$columns = $table->getColumns();
что дает набор полей и их основных характеристик, и далее пляшет от этой печки плюс определенных при создании модуля опций.
***
Ну вот так как-то. Ога, это пока кривовато, зато ставится достаточно легко и настраивается тоже неплохо. Что, впрочем, не исключает необходимости ваять следующую версию, которая учтет косяки предыдущей.