Александр Туниеков

Кто реально внедрил MODX с Vue. js — каков опыт?

Опыт — реактивные переменные благословение и проклятие Vue. С ними можно делать почти мнгновенно реагирующий интерфейс и неприятность что в них не всегда оказывается то что нужно. Где то в коде именил или не изменил не так как нужно и приложение ведет себя не так как нужно. Отследить изменения тяжело особенно если меняешь чужой код или код ИИ

Я делаю miniERP систему на модекс. ИИ помогает значительно. Но с ИИ лучше делать когда сам понимаешь как сделать. Нейросеть не догоняет весь контекст. И сочиняет на ходу чтобы как-бы выполнить задачу. Правда у меня нейросеть хотя бы пытается что-то сделать, а люди сразу в ступор впадают :-). Непривычный контекст задач и тяжело въехать.
Я делаю систему с нейросетью используя modExtra и PVExtra, так как IDE заточены под файлы и в базу не лезут. А в MODX пользовательский код обычно в базе. То есть ставлю чистый MODX. Делаю на нем ЧПУ и делаю компоненты которые заполняют сайт. Возможно имеет смысл подключить к нейросети MCP MySQL и чтоб нейросеть напрямую редактировала страницы и шаблоны. Чанки, сниппеты и тв в последнее время не использую. Вместо сниппетов vue компоненты к которым чанки не особо прикрутишь. А вместо тв проще нужные таблицы сразу писать.
Мне проше сразу писать компоненты. Некоторые потом можно отдельно выкладывать. И проще в прод вносить изменения. Просто поставил компонент и нужные правки применились. И не надо делать деплой всего сервера. Правки по компонентам и нужно поставить лишь тот компонент в котором изменения.

С нейросеть у меня 2 метода писать код:
1. Точечное промт-програмирование. Например, пишешь промпт: здесь отсортируй массив по возрастанию ранга наряда. И нейросеть вставляет нужный код.
2. Вайб-кодинг. Есть задача которую непонятно как сделать и пишешь, например, нужно сделать дополнительные фильтры чекбоксы которые выводят список значений в таблице и при выборе которых в таблице фильтруется по этим выбранным значениям. И нейросеть сама разбирается что сделать и пишет код. Такой промпт я как-то задавал и потом 3 часа разбирался почему основные фильтры не работают. Оказалось что нейросеть решила, что если есть допфильтры, то основные не нужны :-).

3 месяц писал с Kilo Code для VSCode. Но постепенно работа через API Claude стала забирать все больше денег. Сейчас использую Claude Code для VSCode с подпиской MAX. Она втрое дешевле должна выходить. Вчера сочинял с ним план внедрения в miniERP продажи перепродоваемых товаров (вместе с товарами которые мы изготавливаем). Перед использованием вайб-кодинга лучше с ИИ сочинить план разработки.

Ну вкратце так. Более подробно пока желания писать нет. Хотя есть моменты которые хочется обсудить или написать статьи, но прям сейчас только то что написал.

Мнда… Реализация неожиданная для меня.
Во первых, нет переводов primeVue. То есть если использовать фильтры DataTable или Calendar, то они будут англискими. Посмотрел. В минишоп3 похоже фильтры DataTable не используются.
Во вторых, хотел посмотреть реализацию лексиконов, чтобы наконец реализовать их у себя. Но лексиконы, как оказалось, просто берутся из стандартного js файла админки. То есть, для фронта это решение не подходит :-(.
В третьих, usePermission тоже просто берет разрешения из window.MODx?.perm. То есть, все равно нужно реализовать безопасность на беке. usePermission только для информирования пользователя.

Ну хотелось бы что-то более крутое. А так пользоваться можно, но не для меня :-).

Интересно. И самое интересное исходники. Посмотреть как все реализованно. Можно ссылку на исходники? Упс. Нашел исходники

Полез смотреть код и похоже @ВитОс его откатил :-(. Пустые коммиты только вижу.

Специально для тебя. Купил поставил компонент и разобрался с ошибкой :-).
В файле core/components/msorderfields/model/msorderfields.class.php заменить строку 234 на

$query->sortby('`rank`', 'asc');

То есть поставить кавычки у rank. Вроде все работает. Если что-то не работает, то искать где rank без кавычек в sql уходит.
Если хочешь отблагодарить, то стоимость пакета 490р плюс час работы 1000р. Ссылка отправить деньги в профиле.

Забыл что платное… Но 490р и 180 загрузок. Около 60т.р. Делалось неделя две. Ну расход на уровне дохода (плюс минус в 2 раза).

Предлагаю автору дополнения пробежаться по коду и поправить)

Красавчик. Вот автор взял и побежал править. На дня 3 упорной отладки :-). Я у автора копировал файл менеджера допполей и адаптировал под себя. На mySQL8 не смотрел, но на modx3 пробовал переделать. Сделал, но не долго работало. Что-то не доправил.
Для себя решил сижу на modx2.8, myqsl 5.7, php7.4 и не парюсь над этими новыми ихними замутами. Разобраться можно, но дорогостояще по времени и нервам.

Сложностей мне и так хватает. У меня gtsAPI используется в работе. А для документации и кейсов делать слишком длинные уроки разве разумно?

в таком случае мы лишаемся пост обработки…

Верно. Поэтому у меня есть триггеры, корорые можно привязать к какой-то операции, и кастомные действия, которые можно сделать иногрируя стандартные. Это вообще-то минус что так приходиться делать, но вот есть 10 таблиц и кастомное действие требуется только на одной

То есть, экономия времени, как я считаю большая.

повторюсь еще раз стандартный extJS никак не ограничивает бекенд

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

вот это для меня вообще не очень понятно… я правильно понимаю, что вы в 1 файл запихали весь функционал и говорите, что это лучшее решение?

Хм… С одной стороны весь функционал не в 1 файле. Там много файлов во всем функционале. Проще писать по сравнению с extJs и некоторыми знакомыми мне апи. Я особо много их не знаю. По сравнению с extJs. В нем для создания, редактирования, чтения и удаления записи из 1 таблицы надо написать обработку этих операций в js и написать 4 процессора в php. А в gtsAPI операции CRUD для любой таблицы уже реализованы. Их надо только включить и задать права доступа.

Тикетс уже самолет. На уроков 10 объяснений как и что :-).

Может у кого-нибудь есть идея какое приложение написать в качестве демонстрации возможностей? Такое как Sendex, которое Василий написал как демонтстацию extJs.

не обессудьте но с такой документацией — это очень наврятли.

Тут преодолеть порог входа. Мне как создателю почти все понятно и очевидно, а другим думаю чтоб въехать напрячься, потратить время, надо. Это барьер который мешает другим и освоить и развивать другим. И мне не особо понятно как писать документацию, чтоб другим легче было.

то тут все что угодно

Да все что угодно и на более современном фреймворке (vue) и быстрее, когда въедешь, чем и на extJs и на других апи. За счет того, что не надо писать кучу контроллеров.
Только не понятно как документацию свести в удобную систему. Как всегда сперва hello word, а затем сразу строим самолет :-).

Что РКН с инетом делает?? гитхаб не открывается, а впн помогло :-(

К сожалению, не понимая думаю можно наделать других дырок. Попробовал проверить на уязвимость из https://habr.com/ru/articles/130826/ .

Вроде не уязвимо :-). Почти все через pdoFetch идет. Только иногда использую сложное условие вроде (id IN (2,3) and (parent = 4 or parent IS NULL)) в where. Тогда… хм. проверю :-).

Код для проверки:

<?php
$pdo = $modx->getService('pdoFetch');
$id = $_GET['id'];
$pdo->setConfig([
    'class'=>'modResource',
    'where'=>[
        0=>"(id = $id and (parent = 4 or parent = 0))"
    ],
    'limit'=>0,
    'return'=>'data'
]);

$ress = $pdo->run();
foreach($ress as $res){
    echo "<p>{$res['id']}</p>";
}
echo '<pre>'.$pdo->getTime().'</pre>';

На запрос gettables.ru/test.html?id=4+OR+1 выдало:

1

2

3

4

5

6

7

14

16

19

20

21

22

25

30

0.0000529: xPDO query object created
0.0000019: Processed additional conditions
0.0000720: Added where condition: 0=(id = 4 OR 1 and (parent = 4 or parent = 0))
0.0000749: Sorted by modResource.id, ASC
0.0002530: SQL prepared "SELECT * FROM `modx_site_content` AS `modResource` WHERE (id = 4 OR 1 and (parent = 4 or parent = 0)) ORDER BY modResource.id ASC "
0.0014510: SQL executed
0.0000789: Rows fetched
0.0000720: Returning raw data
0.0167792: Total time
4 194 304: Memory usage

Выдало все id страниц. То есть

'where'=>[
        0=>"(id = $id and (parent = 4 or parent = 0))"
    ],

Уязвимо для инъекций. Будем знать.

Безопасность MODX для меня не слишком понятная тема. Когда то искал как безопасно писать запросы в базу. Нашел только приводить к инт все id получаемые с фронта. И плюс вырезать из получаемого с фронта теги MODX и fenom. Было бы интересно увидеть разбор безопасности MODX, при запросах в базу. И увидеть примеры атак, чтобы знать от чего защищаться.

Сложный вопрос. Застали в расплох. Как правильно ответить долго думать. Попробую ответить как смогу. Не обессудте.
Как правильно заметил @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 вас заинтересует.

А чем она должна быть лучше??? Просто тупо програмирую интерфейс пользователя без extjs. У меня там много всякого. На extjs гемор это делать. Vue удобней.

Печалька. Вот казалось человек а на проверку мнит себя самым умным :-(