gtsAPI - компонент API для MODX
Так как у нас нет дизайнера, и на каждый чих искать дизайнера-фрилансера нет желания, возникает проблема обернуть функционал нашего сайта в красивую обертку. Изучать глубоко верстку нет желания и времени. Гораздо проще воспользоваться каким-то UI фреймворком. Тем более многие нужные блоки в них уже хорошо реализованны.
Современные UI фреймворки, такие как Quasar и PrimeVue, общаются с сайтом посредством какого-либо API. Дефолтная реализация API в MODX меня не устроила и я сейчас пишу свою реализацию API для MODX — gtsAPI.
Основная фишка gtsAPI — это то что для большинства нужных операций с таблицами базы данных нужно только настроить правила. А все остальное берет на себя компонент. То есть, нам не нужно для 200 таблиц нашей базы данных писать отдельные контроллеры :-). Сделал c некоторой поддержкой RestAPI.
Гитхаб https://github.com/touol/gtsAPI
Транспортный пакет gtsapi-1.0.0-beta.transport.zip
При установке пакета устанавливается getTables.
Правила обработки API запросов настраиваются в админке в пакете gtsAPI.
Для каждого правила можно прописать точку монтирования, контроллер запросов, разрешения на доступ, пакет и таблицу базы, задать выполняемый запрос к базе при чтении в формате pdoTools.
Точка монтирования. gtsAPI принимает запросы в формате, например, api/orgs. orgs здесь точка монтирования. Можно написать в формате security/login.
Контроллер запросов. Можно написать свой кастомный контроллер, который будет обрабатывать запросы, а можно оставить пустым и запросы будет обрабатывать дефолтный контроллер, который умеет читать и писать (GRUD) в любую таблицу MODX, только нужно для него указать пакет, таблицу базы и разрешения.
Разрешения на доступ. Можно потребовать, чтобы пользователь был аутентифицирован, задать группу пользователей имеющих доступ и можно задать, чтоб у пользователя было какое-то разрешение MODX. Для многих задач достаточно аутентификации. Разрешения MODX довольно долго настраивать и бывает проще просто указать группу.
Для дефолтового контроллера также нужно указать доступные действия.
Для них можно отдельно настроить разрешения.
Запросы в API можно отправлять в 2 форматах.
Либо RestFullApi такие как
Создать пользователя: PUT api/users
Удалить пользователя: DELETE api/users/1
Получить всех пользователей: GET api/users
Получить одного пользователя: GET api/users/1
Либо POST api/users с параметром action=read
Запрос к базе при чтении в формате pdoTools. Можно задать json массив
Для тестирования и чтобы научиться работать с UI фреймворком написан компонент заготовка modPrimeVueExtra
Современные UI фреймворки, такие как Quasar и PrimeVue, общаются с сайтом посредством какого-либо API. Дефолтная реализация API в MODX меня не устроила и я сейчас пишу свою реализацию API для MODX — gtsAPI.
Основная фишка gtsAPI — это то что для большинства нужных операций с таблицами базы данных нужно только настроить правила. А все остальное берет на себя компонент. То есть, нам не нужно для 200 таблиц нашей базы данных писать отдельные контроллеры :-). Сделал c некоторой поддержкой RestAPI.
Гитхаб https://github.com/touol/gtsAPI
Транспортный пакет gtsapi-1.0.0-beta.transport.zip
При установке пакета устанавливается getTables.
Правила обработки API запросов настраиваются в админке в пакете gtsAPI.
Для каждого правила можно прописать точку монтирования, контроллер запросов, разрешения на доступ, пакет и таблицу базы, задать выполняемый запрос к базе при чтении в формате pdoTools.
Точка монтирования. gtsAPI принимает запросы в формате, например, api/orgs. orgs здесь точка монтирования. Можно написать в формате security/login.
Контроллер запросов. Можно написать свой кастомный контроллер, который будет обрабатывать запросы, а можно оставить пустым и запросы будет обрабатывать дефолтный контроллер, который умеет читать и писать (GRUD) в любую таблицу MODX, только нужно для него указать пакет, таблицу базы и разрешения.
Разрешения на доступ. Можно потребовать, чтобы пользователь был аутентифицирован, задать группу пользователей имеющих доступ и можно задать, чтоб у пользователя было какое-то разрешение MODX. Для многих задач достаточно аутентификации. Разрешения MODX довольно долго настраивать и бывает проще просто указать группу.
Для дефолтового контроллера также нужно указать доступные действия.
Для них можно отдельно настроить разрешения.
Запросы в API можно отправлять в 2 форматах.
Либо RestFullApi такие как
Создать пользователя: PUT api/users
Удалить пользователя: DELETE api/users/1
Получить всех пользователей: GET api/users
Получить одного пользователя: GET api/users/1
Либо POST api/users с параметром action=read
Запрос к базе при чтении в формате pdoTools. Можно задать json массив
{
"class": "sraschet",
"leftJoin": {
"modUserProfile": {
"class": "modUserProfile",
"on": "modUserProfile.internalKey = sraschet.manager_id"
},
"tSkladOrders": {
"class": "tSkladOrders",
"on": "tSkladOrders.id = sraschet.sk_order_id"
}
},
"select": {
"modUserProfile": "modUserProfile.fullname",
"sraschet": "*",
"tSkladOrders": "tSkladOrders.excel_id"
}
}
Сейчас gtsAPI только тестируется и возможно, в течении месяцев 2, формат ответов дефолтного контроллера несколько измениться.Для тестирования и чтобы научиться работать с UI фреймворком написан компонент заготовка modPrimeVueExtra
Поблагодарить автора
Отправить деньги
Комментарии: 6
Как-то сложновато пока, хорошо бы документацию потом подробную разработать с примерами.
Чувствуется серьезный подход.
Народ давай поддержим Александра, хорошее дело делает.
А то как-то печально что как-то маловато выкладывают примеров работы MODx с Vue.js и сторонними библиотеками.
Чувствуется серьезный подход.
Народ давай поддержим Александра, хорошее дело делает.
А то как-то печально что как-то маловато выкладывают примеров работы MODx с Vue.js и сторонними библиотеками.
Спасибо за донат. Хотел в заметке спросить надо ли дальше и подробнее описывать :-) но уже запарился. Теперь буду знать. Надо расписывать. Только блоками работы поменьше, чтоб не запариваться и чтоб понятнее было. А стартовый блок работы получился большим. Я насчитал 60 часов работы О_О.
Я правильно понимаю, в таблице можно указать куда слать запрос, где искать код обработчика и можно работать с сайтом через API?
Да правильно. Сложновато написал. Хорошо еще что сейчас начал описывать. Потом вообще бы тяжко было все хитро сплетения прописывать.
В таблице указываешь точку монтирования — это куда слать запрос. Указываешь класс контроллера и путь к нему — то есть это где искать код код обработчика.
Но фишка то в том чтоб по возможности код обработчика вообще не писать. Класс контроллера остовляешь пустым и указываешь нужную таблицу и GRUD API уже есть. Думаю это съэкономит время.
В таблице указываешь точку монтирования — это куда слать запрос. Указываешь класс контроллера и путь к нему — то есть это где искать код код обработчика.
Но фишка то в том чтоб по возможности код обработчика вообще не писать. Класс контроллера остовляешь пустым и указываешь нужную таблицу и GRUD API уже есть. Думаю это съэкономит время.
Не могу представить кейс, в котором не нужно было бы писать свою логику. А в целом вариант быстро накидать точки монтирования и дальше работать непосредственно с кодом это круто)))
Хм. Я чет не подумал что у меня ситуация отличается. У меня 200 таблиц в базе и на фронте. Писать контроллер на каждую таблицу замучишься. А для большинства таблиц как раз только GRUD и требуется. Под это и заточено. Еще перенести функионал getTables на PrimeVue и треть работы сделана :-)
Авторизуйтесь или зарегистрируйтесь, чтобы оставлять комментарии.