PVAdmin мини-админка для MODX 2.8
Наконец я добрался до создания админки для MODX. Реализовал только необходимый нам функционал, но при необходимости всё можно доработать — это не очень сложно. В gtsAPI теперь есть все необходимые модули. Также можно использовать эти модули для других проектов.

Здесь реализованы:
1. Дерево ресурсов MODX.
2. Собственная галерея файлов.

3. Дерево файлов.

4. Управление пользователями.

Установка
Перед установкой PVAdmin установите gtsAPI (getTables и pdoTools, если они не установлены) и Login. Необходимо настроить ЧПУ MODX. Включить Использовать Fenom на страницах.
Установите пакет pvadmin-1.0.1-beta.transport.zip из репозитория пакета https://github.com/tuniekov/PVAdmin/.
Важно
gtsAPI работает на MODX 2.8, MySQL 5.7 или последней версии MariaDB, PHP 7.4. На остальных конфигурациях работа не тестировалась.
Upd. Пару ошибок пропустил :-(. Их уже поправил, но еще проверю. Завтра новую версию опубликую.
Upd 2. Обновил. Вроде все работает.

Здесь реализованы:
1. Дерево ресурсов MODX.
2. Собственная галерея файлов.

3. Дерево файлов.

4. Управление пользователями.

Установка
Перед установкой PVAdmin установите gtsAPI (getTables и pdoTools, если они не установлены) и Login. Необходимо настроить ЧПУ MODX. Включить Использовать Fenom на страницах.
Установите пакет pvadmin-1.0.1-beta.transport.zip из репозитория пакета https://github.com/tuniekov/PVAdmin/.
Важно
gtsAPI работает на MODX 2.8, MySQL 5.7 или последней версии MariaDB, PHP 7.4. На остальных конфигурациях работа не тестировалась.
Upd. Пару ошибок пропустил :-(. Их уже поправил, но еще проверю. Завтра новую версию опубликую.
Upd 2. Обновил. Вроде все работает.
Поблагодарить автора
Отправить деньги
Комментарии: 16
А чем эта админка лучше стандартной?
А чем она должна быть лучше??? Просто тупо програмирую интерфейс пользователя без extjs. У меня там много всякого. На extjs гемор это делать. Vue удобней.
Переформулирую вопрос. Какую проблему или проблемы ты решал, когда делал свою админку? Какие возможности даёт другим разработчикам твоя админка? Как ими воспользоваться?
Как понял из предыдущих постов автора — это не для обычных сайтов. У них там сложный технологический процесс, и нужно, чтобы участники этого процесса могли загружать множество технических параметров для своих деталей — видимо обычная админка этого не позволяет. Но вот что это дает разработчикам обычных сайтов — пока не понятно.
Сложный вопрос. Застали в расплох. Как правильно ответить долго думать. Попробую ответить как смогу. Не обессудте.
Как правильно заметил @Futuris, у нас сложный технологический процесс, и запрограммировать множество технических параметрев деталей на extJs очень долго. Для примера, я в начале года пытался перевести тикеты на modx3. Так в них 50 процессоров для разных действий (https://github.com/tuniekov/Tickets/tree/master/core/components/tickets2/src/Processors). gtsAPI устроен так, что ему не нужны куча контролеров. Прописываешь настройки доступа и отображения для таблицы и всем процессом управляет 1 уже написанный контроллер. Это в разы сокращает время написания приложения. Хотя и вносит некоторые ограничения :-). Так вот, чтобы прописать нужный нам функционал на extJs, наверно бы потребовалось написать 500-1000 процессоров.
В примере админки на Vue, PVAdmin, я написал в основном, только нужный нам функционал для менеджеров и инженеров ИТР. Полностью повторять админку MODX у меня задача не стояла. Для стандартных целей админка MODX меня полностью устраивает. Админка PVAdmin, в текущей реализации, нужна только если програмировать сложный функционал или нет желания пускать пользователей в стандартную админку MODX.
Но программировать на Vue с gtsAPI, по моему, гораздо проще, чем на extJs. Если писать приложения вроде Tickets для PVAdmin, то может быть, со временем админка на Vue будет удобнее для обычных сайтов. Пока Tickets для PVAdmin не планирую, но есть некоторый соблазн :-).
Мои заметки по gtsAPI:
UniTree новые возможности gtsAPI-PVTables
Кейс gtsAPI. CRUD пользователей на фронте
gtsAPI — Универсальное API для MODX
Введение в PVTables
Компонеты для gtsAPI проще писать на основе https://github.com/tuniekov/PVExtra. В readme инструкция.
Сейчас изучать gtsAPI наверно проще по примерам:
https://github.com/tuniekov/OrgStructure
https://github.com/tuniekov/PVAdmin/.
Основные файлы:
В файле _build\configs\gtsapipackages.js настройки таблиц для gtsAPI. По ним gtsAPI и PVTables формируют доступное API и таблицы, деревья, формы на фронте.
В файле core\components\pvextra\model\schema\pvextra.mysql.schema.xml MODX схема базы данных
В файле core\components\pvextra\model\pvextra\pvextra.class.php класс MODX компонента. Триггеры и кастомные действия обращаются в него.
src/App.vue код приложения на vue.
В папке https://github.com/tuniekov/PVExtra/tree/main/docs документация ИИ для ИИ. Часто в нейросеть пишу промпт: Прочитай docs/use_gtsapipackages.md и напиши конфиг для таблицы tableName (например, modUser или modUserProfile).
Надеюсь хорошо ответил… Буду рад если gtsAPI вас заинтересует.
Как правильно заметил @Futuris, у нас сложный технологический процесс, и запрограммировать множество технических параметрев деталей на extJs очень долго. Для примера, я в начале года пытался перевести тикеты на modx3. Так в них 50 процессоров для разных действий (https://github.com/tuniekov/Tickets/tree/master/core/components/tickets2/src/Processors). gtsAPI устроен так, что ему не нужны куча контролеров. Прописываешь настройки доступа и отображения для таблицы и всем процессом управляет 1 уже написанный контроллер. Это в разы сокращает время написания приложения. Хотя и вносит некоторые ограничения :-). Так вот, чтобы прописать нужный нам функционал на extJs, наверно бы потребовалось написать 500-1000 процессоров.
В примере админки на Vue, PVAdmin, я написал в основном, только нужный нам функционал для менеджеров и инженеров ИТР. Полностью повторять админку MODX у меня задача не стояла. Для стандартных целей админка MODX меня полностью устраивает. Админка PVAdmin, в текущей реализации, нужна только если програмировать сложный функционал или нет желания пускать пользователей в стандартную админку MODX.
Но программировать на Vue с gtsAPI, по моему, гораздо проще, чем на extJs. Если писать приложения вроде Tickets для PVAdmin, то может быть, со временем админка на Vue будет удобнее для обычных сайтов. Пока Tickets для PVAdmin не планирую, но есть некоторый соблазн :-).
Как ими воспользоваться?Я пишу документацию временами и почти не получаю обратную связь от других разработчиков и пользователей. Так что сейчас документация не слишком хороша. Надеюсь, это исправиться. Преимущества Vue с gtsAPI в том что можно быстрее и проще програмировать компоненты для PVAdmin.
Мои заметки по gtsAPI:
UniTree новые возможности gtsAPI-PVTables
Кейс gtsAPI. CRUD пользователей на фронте
gtsAPI — Универсальное API для MODX
Введение в PVTables
Компонеты для gtsAPI проще писать на основе https://github.com/tuniekov/PVExtra. В readme инструкция.
Сейчас изучать gtsAPI наверно проще по примерам:
https://github.com/tuniekov/OrgStructure
https://github.com/tuniekov/PVAdmin/.
Основные файлы:
В файле _build\configs\gtsapipackages.js настройки таблиц для gtsAPI. По ним gtsAPI и PVTables формируют доступное API и таблицы, деревья, формы на фронте.
В файле core\components\pvextra\model\schema\pvextra.mysql.schema.xml MODX схема базы данных
В файле core\components\pvextra\model\pvextra\pvextra.class.php класс MODX компонента. Триггеры и кастомные действия обращаются в него.
src/App.vue код приложения на vue.
В папке https://github.com/tuniekov/PVExtra/tree/main/docs документация ИИ для ИИ. Часто в нейросеть пишу промпт: Прочитай docs/use_gtsapipackages.md и напиши конфиг для таблицы tableName (например, modUser или modUserProfile).
Надеюсь хорошо ответил… Буду рад если gtsAPI вас заинтересует.
Буду рад если gtsAPI вас заинтересует.не обессудьте но с такой документацией — это очень наврятли.
я понимаю вы старались, наверное из всего только дерево интересно, а остальное в итоге тот-же extjs получится только без доков
Самое главное — это не создать, а поддерживать и развивать и по возможности не только вашим гением(никакого сарказма)
Вообще я так понял это не столько админка как интерфейс для манагера… то тут все что угодно, иногда и такое нужно
не обессудьте но с такой документацией — это очень наврятли.Тут преодолеть порог входа. Мне как создателю почти все понятно и очевидно, а другим думаю чтоб въехать напрячься, потратить время, надо. Это барьер который мешает другим и освоить и развивать другим. И мне не особо понятно как писать документацию, чтоб другим легче было.
то тут все что угодноДа все что угодно и на более современном фреймворке (vue) и быстрее, когда въедешь, чем и на extJs и на других апи. За счет того, что не надо писать кучу контроллеров.
Только не понятно как документацию свести в удобную систему. Как всегда сперва hello word, а затем сразу строим самолет :-).
И мне не особо понятно как писать документацию, чтоб другим легче было.how to это конечно полезно, но и только — это мало, добавьте ссылок на оф доку фреймворка.
чем и на extJs и на других апине ну это уже перебор, считать, что ваш подход единственно верный
Есть такое выражение в принципе: Самый лучший язык программирования тот, что ты знаешь в совершенстве.
Т.е. по факту ты можешь прийти к одинаковому результату(усилие + время) используя те инструменты которые ты лучше знаешь, а не те про которые громче крикнули.
За счет того, что не надо писать кучу контроллеров.вот это для меня вообще не очень понятно… я правильно понимаю, что вы в 1 файл запихали весь функционал и говорите, что это лучшее решение?
ЗЫ
Поймите меня правильно, я не смотрел внутренности вашего решения, но хотелось бы уточнить вашу логику до погружения. Т.е. я не топлю за extJs и иже с ними, но логику и мотивы хочется от вас получить
вот это для меня вообще не очень понятно… я правильно понимаю, что вы в 1 файл запихали весь функционал и говорите, что это лучшее решение?Хм… С одной стороны весь функционал не в 1 файле. Там много файлов во всем функционале. Проще писать по сравнению с extJs и некоторыми знакомыми мне апи. Я особо много их не знаю. По сравнению с extJs. В нем для создания, редактирования, чтения и удаления записи из 1 таблицы надо написать обработку этих операций в js и написать 4 процессора в php. А в gtsAPI операции CRUD для любой таблицы уже реализованы. Их надо только включить и задать права доступа.
А в gtsAPI операции CRUD для любой таблицы уже реализованы. Их надо только включить и задать права доступа.в таком случае мы лишаемся пост обработки…
повторюсь еще раз стандартный extJS никак не ограничивает бекенд
Много правильно названных файлов — это хороший тон а не обязательство
в таком случае мы лишаемся пост обработки…Верно. Поэтому у меня есть триггеры, корорые можно привязать к какой-то операции, и кастомные действия, которые можно сделать иногрируя стандартные. Это вообще-то минус что так приходиться делать, но вот есть 10 таблиц и кастомное действие требуется только на одной

То есть, экономия времени, как я считаю большая.
повторюсь еще раз стандартный extJS никак не ограничивает бекендНу extJs не ограничивает. Просто множество процессоров стандартная методика в MODX. Которая, как я считаю, является скучной и бессмысленой работой :-). Так то можно написать аналог gtsAPI для extJs. Только мне это не требуется. А вообще первоначально я вдохновлялся migx. gtsAPI для таблиц — это, грубо говоря, тот же самый migx для vue. А дерево UniTree это развитие этой идеи на деревья.
Может у кого-нибудь есть идея какое приложение написать в качестве демонстрации возможностей? Такое как Sendex, которое Василий написал как демонтстацию extJs.
да тот-же Тикетс реализуйте
Тикетс уже самолет. На уроков 10 объяснений как и что :-).
ну вот в сложном как раз и проявится работает ли ваш подход или всетаки нужно что-то пересмотреть
Сложностей мне и так хватает. У меня gtsAPI используется в работе. А для документации и кейсов делать слишком длинные уроки разве разумно?
Авторизуйтесь или зарегистрируйтесь, чтобы оставлять комментарии.