CMS. Админ-панель
Потихонечку продвигаюсь со своей CMS и уже занимаюсь админкой. Можно было бы наскоком прописать нужные функции и темплейт, но решил не спешить, и сделать так, чтобы админка была не вещью в себе, а выполняла лишь роль менеджера.
Подход, который я решил применить заключается в том, чтобы отказаться от тяжеловесных админских функций и перенести «физическую нагрузку» на плагины (или что-то аналогичное).
Получилась такая схема.
1. Вход в админку происходит по адресу http://site/admin/действие/параметры
2. «Действие» - это плагин или какая-то функция, которой передается управление. «Параметры» - с этим уже сама функция будет разбираться.
3. Сама же админка представляет собой html-темплейт, где прописаны четыре функции: mso_admin_header(), mso_admin_menu(), mso_admin_content(), mso_admin_footer(). Из названий понятно для чего они предназначены.
4. Теперь для того, чтобы вывести скажем настройки какого-либо плагина, мы просто вешаем (в плагине) хук на admin_content, а пункт меню добавлем как хук на admin_menu.
5. Таким образом подключить любой плагин к админке очень просто. Это буквально пара функций.
Конечно предстоит еще решить вопрос о дефолтных настройках/страницах, но в целом они ничем не будут отличаться от подключения тех же плагинов.
Следующая проблема с которой мне пришлось столкнуться - это админские функции по управлению базой. «Классический» подход заключается в том, чтобы наделать функций по управлению, создать html-формы и все это автоматом вызывать при входе в админ-панель.
Проблема здесь в том, что этих функций будет много и они будут между собой взаимосвязаны. Если нужно будет что-то изменить, то эта цепочка может протянуться очень далеко. В том же WordPress'е админка - это что-то невообразимое: огромное количество функций, которые не только переплетены между собой, но еще и тянутся к функциям в wp-include. Понятно, что изменить админку в WordPress очень и очень сложно. Всё, на что можно «позариться», так это смена css-стилей.
Лично мне такой подход не нравится, поскольку он очень сильно сужает рамки функциональности. Предположим нам нужно сделать страницу списка записей. В «классическом» варианте нам нужно было бы сделать отдельный php-файл, жестко его «прикрепить» к админке, написать все функции, выполнить SQL-запрос и выполнить форматирование полученных данных. Если пойти по такому пути, то неизбежно прийдем к «тяжелой» админке.
Теперь, предположим, появляется другой плагин, который выполняет примерно тоже самое, но выводит данные по-другому. В третьем случае мы хотим получить выборку данных для еще каких-то действий. Во всех этих случаях мы выполняем по сути одно и тоже действие - получение данных, а вот отображение может быть различным. Получается, что есть смысл унифицировать основные действия в системе, чтобы вызывать их одной функцией.
Таким механизмом является XML-RPC. В кратце я расскажу что это такое.
В XML-RPC есть две стороны: сервер и клиент. Сервер - это некий php-скрипт, который принимает входящие данные (запрос) и, согласно этому запросу, выполняет определенное действие (метод, функцию). Клиент в свою очередь - это обычный POST, только данные в нем передаются в виде XML-структуры. Например нам нужно получить список последних записей. В запросе мы указываем свой логин, пароль, название метода и количество записей. Отправляем этот запрос и в ответ получаем список последних записей.
Именно так работают оффлайн-клиенты (блог-клиенты). Как видите клиенту совершенно не обязательно знать все тонкости внутренней реализации методов. Все, что ему требуется, так это название метода и его параметры.
Теперь, перенеся эту технологию на нашу админку, мы получаем, что функция для админки должна просто-напросто сформировать XML-запрос к своему же серверу и получить необходимые данные.
Что же получается в итоге.
1. Админка не несет «тяжелых» функций.
2. Простое подключение любых плагинов к админке.
3. Перенос функций для визуального отображения данных в отдельные плагины.
4. Получение данных выполняется через универсальный XML-RPC.
5. В «комплекте» мы сразу же получили работу с блог-клиентами.
На долю самой админки выпадают помимо функции менеджера, еще и работа с разграничением доступа (роли, группы, права), базовые настройки плагинов (включение, отключение, деинсталяция), базовые настройки сайта (выбор шаблона, название, описание и т.п.), то есть только то, что входит в самый минимум: таблицы options и users.
Постоянная ссылка: http://maxsite.org/?p=356
Версия для печати
