Чем серьезнее мы относимся к своим проектам, тем больше нам хочется, чтобы поставленные задачи были решены наилучшим образом.
Например, мы хотим предоставить клиенту качественную систему администрирования в адекватные сроки.
Лично я в такие моменты сразу вспоминаю Джанго: создал модель — получи админку.
Или виджеты в Yii. Или чудесное сочетание хуков и классов в Drupal 7. Или Sonata в Symfony, о которой я, правда, только слышал.
А что, если у нас появится Битрикс?
Администратор Битрикс по фен-шуй
К сожалению, Битрикс, несмотря на попытки разработчиков хоть как-то улучшить ситуацию, во многих своих аспектах остается архаичной системой: процедурные куски кода в несколько сотен строк, возведенные в уровень мануала копипасты, классы, из которых невозможно нормально наследовать - все это по сей день остается реальностью для тех, кому приходится работать с этой системой.И я уверен, что это не исчезнет в ближайшее время.
Что делать разработчику, если ему необходимо создать административный интерфейс для произвольной таблицы в базе данных? По мануалу нам нужно скопировать «рыбку» с кодом в 417 строк – для страницы списка элементов и 365 строк – для страницы редактирования элемента.
Ну или пишем все сами, если мы счастливые обладатели феноменальной памяти.
Что ж, 2016 год начался хорошо! Но у нас пока ничего не работает! После того, как мы выполнили акт копипаста, нам нужно внимательно прочитать 782 строки кода, удалить все лишнее и добавить свое.
А именно:
- Напишите проверку этих фильтров.
- Укажите список столбцов для фильтрации выбора.
- Напишите обработку действий над отдельным элементом и над группой элементов списка.
- Сделайте свой собственный выбор.
И обычно никто не заморачивается, просто делают SELECT*FROM. — в «рыбе» от Битрикса нет предложения ограничить список выбираемых полей только теми, которые необходимы.
- Укажите список столбцов, которые будут отображаться в списке.
- В процессе отображения списка отображайте для каждого столбца определенный элемент управления.
- Отобразите нижний колонтитул таблицы.
- Отобразите фильтр над таблицей.
Я специально указал пункты не в том порядке, в котором подсказывает логика и в котором они отображаются на результирующей странице, а в том порядке, в котором этот код появляется в «рыбке» из мануала.
А что нам нужно сделать, если мы решим, скажем, добавить в список еще одно поле? Или даже просто переименовать какой-то существующий? Мы должны ввести это новое поле в 7 местах или изменить существующее, не допустив ошибки! Ситуация осложняется тем, что вместе с php-кодом в этом же файле есть еще и html, причем совершенно не в том порядке, в котором он отображается на странице, нечитабельный ни вашей любимой IDE, ни человеческому глазу, потому что многие теги генерируются где-то в глубине.
Все это очень сложно ориентироваться.
Особенно, когда страница уже совсем не простая и к тому же содержит JS-код, обычно написанный inline. Что мы получаем в результате? Ошибки.
Сложность поддержки.
Неоправданно большие временные затраты даже при изменении любой мелочи.
Аналогичная ситуация и со страницей редактирования элемента.
Я искренне не понимаю, как можно было столько лет жевать такой кактус?!
Как все могло быть
Как ни странно, API администратора Битрикса спроектирован хорошо.После описанных выше ужасов в это сложно поверить, но это правда.
Потому что проблема не в самом API, а в том, как его потом использовали.
Похоже, что у разработчиков API были какие-то планы на будущее или просто какие-то смутные представления, но они не сделали простой и логичный следующий шаг: создание набора классов MVC. Вероятно, причиной этого является отсутствие до недавнего времени единого интерфейса работы с базой данных.
После просмотра большого разнообразия самописных админ-панелей становится понятно, что независимо от сложности и специфики задачи процесс построения админ-панели включает в себя те же этапы, которые я описал выше.
Это означает, что код везде один и тот же, остается только изменить входные данные.
Вы можете выбрать следующие сущности без привязки к коду:
- Конфигурация интерфейса: список полей, которые будут использоваться для формирования фильтров, списка столбцов таблицы или набора входных данных на странице редактирования.
- Класс представления для отображения интерфейса.
На входе он должен получить конфиг, «под капотом» у него будет вся логика, которую мы видим в «рыбе» от Битрикса, а на выходе он выдаст отрендеренную страницу.
- Виджет. Содержит логику работы отдельного админ-поля.
В списке он используется для рисования ячеек таблицы, а на странице редактирования – полей элементов.
описанная схема.
Реализуя описанные выше классы, мы смогли существенно уменьшить «рыбку» из Битрикса до чего-то похожего:
В этом семистрочном фрагменте кода описаны основные этапы создания панели администратора, описанные в начале статьи.$fields = include(‘fields.conf.php’); $adminListHelper = new MyHelper($fields); $adminListHelper->buildList(array($by => $order)); require($_SERVER["DOCUMENT_ROOT"] ."/bitrix/modules/main/include/prolog_admin_after.php"); $adminListHelper ->createFilterForm(); $adminListHelper ->show(); require($_SERVER["DOCUMENT_ROOT"] .
"/bitrix/modules/main/include/epilog_admin.php");
Но вместо того, чтобы каждый раз копировать этот, пусть и небольшой, фрагмент, лучше поработать еще немного и сделать следующее:
- пропишите приведенный выше код в специальный файл Route.php, в который будут перенаправляться все запросы к административному интерфейсу, созданному через нашу надстройку к API Битрикс;
- в файле с описанием конфига интерфейса прописать этот конфиг в какой-нибудь глобальной переменной или переменной статического класса;
- при обращении к страницам административного интерфейса использовать не прямые URL, а псевдонимы и функции, конструирующие из этих псевдонимов правильный URL;
- в конечном итоге все запросы будут поступать в маршрут.php, который будет разбираться, какой класс нужно создать, какой конфиг интерфейса ему передать и как все это выводить.
class TableListHelper extends AdminListHelper
{
static protected $model = 'MyModelTable';
static public $module = 'my.module';
static protected $viewName = 'table_list';
static protected $editViewName = 'table_detail';
}
Изменить класс страницы
class TableEditHelper extends AdminEditHelper
{
static protected $model = 'MyModelTable';
static public $module = 'my.module';
static protected $listViewName = 'table_list';
static protected $viewName = 'table_detail';
}
Настройки интерфейса
AdminBaseHelper::setInterfaceSettings(
array(
'FIELDS' => array(
'ID' => array(
'WIDGET' => new NumberWidget(),
'TITLE' => 'ID',
'TAB' => 'TAB_ONE'
),
'STRING' => array(
'WIDGET' => new StringWidget(),
'TITLE' => 'STRING',
'TAB' => 'TAB_ONE'
),
'NUMBER' => array(
'WIDGET' => new NumberWidget(),
'TITLE' => 'NUMBER',
'TAB' => 'TAB_ANOTHER'
),
'TEXT' => array(
'WIDGET' => new TextAreaWidget(),
'TITLE' => 'TEXT',
'TAB' => 'TAB_ANOTHER'
)
),
'TABS' => array(
'TAB_ONE' => Loc::getMessage('TAB_ONE'),
'TAB_ANOTHER' => Loc::getMessage('TAB_ANOTHER'),
)
),
array(
'\TableEditHelper',
'\TableListHelper'
),
'my.module'
);
Файл меню.
php $menu = array(
array(
"parent_menu" => "global_menu_services",
"section" => "table",
"sort" => 140,
"text" => Loc::getMessage('TABLE_MENU_TEXT'),
"title" => Loc::getMessage('TABLE_MENU_TITLE'),
"icon" => "table_menu_icon",
"page_icon" => "table_page_icon",
"items_id" => "menu_table",
"url" => TableEditHelper::getListPageURL(),
"more_url" => array(
TableListHelper::getEditPageURL()
),
),
);
return $menu;
Никаких сотен строк копипаста и копирования файлов в /bitrix/admin — и в результате мы получаем вполне рабочую админку для таблицы с четырьмя колонками: страница списка, страница редактирования и ссылки на них в системном меню.
.
С поддержкой операций CRUD «из коробки».
При обычной маршрутизации (в данном примере - /bitrix/admin/route.phpЭmodule=my.module&view=tab_list откроет страницу списка.
Если есть желание или необходимость, вы можете изменить это на «CNC»).
Дальше мы просто переопределяем методы базовых классов, чтобы настроить его поведение под наши задачи.
Выглядит заманчиво, не так ли?
Будущее уже здесь!
А теперь о хорошем: то, что было описано выше, это уже не просто концепция, а реальный, работающий модуль, который уже был в производстве многих проектов, модуль, которым я хотел бы поделиться: github.com/DigitalWand/digitalwand.admin_helper Код становится на несколько порядков лаконичнее, шаблонный копипаст сводится к минимуму, уступая место массивам с конфигурацией, которых в Битриксе в принципе не было:
Сравнение основано на: Документация Битрикс: dev.1c-bitrix.ru/api_help/main/general/admin.section Пример использования модуля: github.com/niksamokhvalov/demo.adminhelper Модуль может работать как с полностью настраиваемыми таблицами, так и с таблицами, созданными за счет функционала Битрикс инфоблоков «Высокая нагрузка», при этом вместо «виджетов» возможно использование классов «настраиваемых свойств».
Таким образом, нам доступен весь функционал, доступный в админке инфолоктов «Highload», только теперь мы можем легко настроить его под свои нужды.
Должен также предупредить читателей, что в данной статье намеренно использован «старый стиль» работы с модулем из его первой версии, чтобы более наглядно продемонстрировать внутренний механизм его работы.
В последних версиях в вспомогательных классах достаточно указать только модель — всё остальное модуль определит сам.
Доступны и другие полезные материалы:
- Небольшая презентация , призванный убедить сторонников «старой школы» и «Битрикс-Пути» перейти на новые «рельсы».
- Схема, иллюстрирующая архитектуру модуля в общих чертах:
Теги: #открытый код #генератор администратора #Битрикс #CMS #открытый код #1С-Битрикс
-
Пять Ключевых Itsm-Трендов Этого Года
19 Oct, 24 -
Ищем Молодую Кровь
19 Oct, 24 -
Devcon 2014: Самая Курортная Конференция
19 Oct, 24 -
Тест Моей Мечты
19 Oct, 24
