modPrimeVueExtra - заготовка для разработки с Vue

Решил перейти на реактивные UI фреймворки и сделал заготовку для более удобной разработки с ними, с MODX и с gtsAPI — компонент API для MODX
У нас на MODX много функционала и сразу перейти на какой-то JS фреймворк нельзя. Как и задумывалось заготовка реализует какой-то смешанный режим разработки между стандартным для Vue путем и путем компонентов MODX.
В заготовке сделан GRUD таблицы базы данных MODX. На основе PrimeVue


В компоненте gtsAPI есть сниппет mixedVue и с помощью него можно вывести блок с компонентом на основе modPrimeVueExtra с любом месте сайта.
{'!mixedVue' | snippet : [
    'app'=>'modPrimeVueExtra'
]}
(только стили бутстрап и PrimeVue друг другу мешают :-()

Быстрый старт
Необходимо установленая NodeJs и VSCode.
Заготовка на гитхабе https://github.com/touol/modPrimeVueExtra
Клонирум ее к себе в папку домен_сайта_разработки/Extras/modPrimeVueExtra. Открываем папку modPrimeVueExtra редактором VSCode.
В терминале устанавливаем пакеты node
npm install
Запускаем скрипт копирования и переименования заготовки
npm run copy
Вводим новое имя пакета, например, PackageName.
В папке домен_сайта_разработки/Extras создается папка PackageName и все ссылки на modPrimeVueExtra в PackageName заменяются на PackageName.

Дальше открываем в VSCode домен_сайта_разработки/Extras/PackageName и редактируем схему базы пакета в файле домен_сайта_разработки/Extras/PackageName/_build\configs\schema.xml

В файле домен_сайта_разработки/Extras/PackageName/_build\configs\gtsapirules.js редактируем правила gtsAPI для этого пакета.

Редактируем PackageName/.env и прописываем свой VITE_APP_HOST

Запускаем скрипт получения токена для разработки
npm run get_token
Вводим логин и пароль. Полученный токен сохраняется в файле PackageName/.env

Запускаем скрипт загрузки и установки пакета в модекс
npm run upconfig
На нужной странице в модекс прописываем вызов сниппета
{'!mixedVue' | snippet : [
    'app'=>'PackageName'
]}
Для режима разработки с Vite в системных параметрах модекс меняем gtsapi_debug_mode на включенно.

Запускаем разработку с Vite
npm run dev
Теперь страница сайта автоматически изменяется при изменение кода в PackageName/src

В папке PackageName/src пишем нужный нам функционал.

После того как окончили разработку отключаем dev режим (q + enter в терминале) и запускаем
npm run build
В папке домен_сайта_разработки/core/packages появиться транспортный пакет который можно скопировать и установить на любой сайт MODX 2.x с установленых gtsAPI.
Александр Туниеков
26 декабря 2023, 17:30
modx.pro
1
1 248
+2
Поблагодарить автора Отправить деньги

Комментарии: 18

deleted
28 декабря 2023, 18:27
0
На нужной странице в модекс прописываем вызов сниппета
А зачем так? У меня сейчас проект на Quasar, MODX возвращает долько страницу с #app. Думаю вообще фронт и бэк разными сайтами сделать, на фронте останется только index.html, сгенерированный Vite, ну и скрипты со стилями.
    Алексей Соин
    28 декабря 2023, 18:36
    0
    для чего вообще для этого тратить столько времени и мучать modx когда есть более удобные и гибкие инструменты?
      Олег Захаров
      28 декабря 2023, 18:38
      0
      Какие конкретно можете подсказать? И чем удобнее?
        Алексей Соин
        28 декабря 2023, 18:50
        0
        strapi, laravel, nestjs, symfony, winter cms и т.д., зависит от задачи которая требуется. Удобнее тем, что можно спроектировать и реализовать конечный продукт полностью удовлетворяющий задаче, а не придумывать 1000 обходных путей и решений из-за ограничений или особенностей modx. Любой инструмент хорош лишь тогда, когда его используют по назначению.
          Олег Захаров
          28 декабря 2023, 18:52
          0
          Для интернет-магазина на 100 000 товаров какой стек технологий порекомендуете?
            Алексей Соин
            28 декабря 2023, 19:06
            0
            modx, битрикс, laravel, если вопрос какой стек выдержит таблицу с таким кол-вом товаров, то любой, при условии профессионализма самого разработчика. Вопрос не совсем корректный, в комментарии на который я отвечал планируется использовать только лишь как админку и апи, для чего изначально modx не подходит и нуждается в доработках (использование zoomx, оптимизировать кэширование и тд). А что будет в этих 100к товарах непонятно, подойдёт ли минишоп и его допы или также надо будет расширять таблицы, какая посещаемость будет у сайта.
              deleted
              28 декабря 2023, 19:15
              0
              для чего изначально modx не подходит и нуждается в доработках (использование zoomx, оптимизировать кэширование и тд).
              Более того, я туда ещё Eloquent прикрутил) Ну вот заказчику именно MODX нужен был. На Ларе настаивать не стал, ибо практически не работал с ней. Хотя всё же подумываю предложить перенести проект на неё, думаю не особо долго будет контроллеры переписать
                Алексей Соин
                28 декабря 2023, 19:18
                0
                а чем заказчику так модх нравится? чисто из-за того что к админке привык?
        Олег Захаров
        28 декабря 2023, 19:33
        0
        Мне кажется что идея API все равно актуальна. Вот заказчик захотел сайт. Сделали сайт, с большим функционалом и множеством плюшек. Много времени пользовались и наполнили данными. А потом Заказчик захочет мобильное приложение связанное с сайтом единой базой. Если использовать инструменты создания кроссплатформенных приложений то как мне думается (могу ошибаться) создав API на сайте через указанный выше gtsAPI и чтобы не изобретать велосипед заново на новом стеке технологий — будет гораздо проще и быстрее.
        Хотя я сам пока такого не делал (так что мое мнение дилетанта), есть перспектива такая после сайта сделать мобильное приложение с подключением данных с сайта.
          Алексей Соин
          28 декабря 2023, 19:49
          +1
          тут множество решений, если на сайт большая нагрузка, то нагружать сервер ещё и апи для мобильного приложения его ещё больше добьёт, можно реплицировать бд и для этой бд сделать апи используя уже любой удобный яп, фреймворк и т.д. Минус при этом будет это параллельная поддержка изменений в двух точках входа. Создав апи на томже сайте с большим функционалом также надо будет не забывать исправив чтото для веб версии поправить также и для апи мобилы. В таком случае более оптимально сделать единое апи для веб и мобилы, так почему бы сразу не потратить это время на перенос всего под оптимальный бэк, использовать для сайта тотже nuxt, next? А если ещё и мобильный клиент собирать на react native или чемто подобным, то можно все изменения и улучшения разпараллелить сразу и для веба и для мобилы. Всё это в конечном итоге будет экономить как и время разработчиков так и деньги заказчиков.
            Александр Туниеков
            28 декабря 2023, 23:32
            0
            можно реплицировать бд и для этой бд сделать апи используя уже любой удобный яп, фреймворк и т.д
            Реплиировать бд это синронизация бд или просто раз скопировать?
            Если раз скопировать, то как функционал который еще не написан, а работать компании нужно? А написать год или 2.
            Если синхронизировать, то это может гемор. Самописно я пробовал и точно гемор. А какой либо софт не знаю не смотрел еще. Если подскажете, будет интересно. И еще многие таблицы исторически созданны не оптимально. Хочется их переопределить, но сайт под эту структуру таблиц уже заточен. При синхронизации хотелось бы переопределить структуру таблиц :-(.
              Алексей Соин
              29 декабря 2023, 00:11
              0
              репликация настраивается на уровне бд, всё это уже есть в mysql, postgres, никакие инструменты искать не надо, репликации можно настраивать в режиме как мастер-мастер, так и в режиме мастер-слейв, то есть вторая база чисто для чтения используется.
        Александр Туниеков
        28 декабря 2023, 23:05
        0
        Ну на модекс написан за 8 лет большой функционал и на другой сервер его маленькими блоками не перекинешь.
        И большими может тоже не перекинешь :-(. Вообщем есть таблица заказов и от нее зависит склад, производство, снабжение, логистика и т.д. Я счас пытаюсь маленькие блоки на vue перевести. Например распределение деталей из заказов по сменам производства. Или хотя бы написать распределение ресурсов(работников) по сменам.
          iWatchYouFromAfar
          17 января 2024, 22:09
          +3
          Если вы работаете на фултайме и хорошо понимаете то, на чем пишите, написать собственный функционал не составит труда. А вот что касается Vue внутри MODx, ну, апплодировать ногами тоже можно, но лишь ради развлечения других людей.

          Пару лет назад я думал — было бы отлично, если бы MODx и его компоненты могли поставлять хороший и удобный REST. Там и админку свою можно набросать и на фронте наконец-то уйти от фенома и сниппетов. Сейчас я понимаю что был ох как не прав, куда проще сесть и начать писать свой бекенд. Вопрос лишь в финансах и желании. Если хотя бы один фактор отсутствует, то хер знает зачем тратить кучу времени и изобретать франкенштейна… Берешь MODx и пользуешь как есть. Товары будут продаваться и без Vue.js.
            Александр Туниеков
            18 января 2024, 05:47
            0
            А вот что касается Vue внутри MODx, ну, апплодировать ногами тоже можно, но лишь ради развлечения других людей.
            Грубовато :-)
            Товары будут продаваться и без Vue.js
            Чисто на товары Vue и не надо. Надо на динамичное приложение. Уже надоело как надо показать какую-то не стандартную модалку, то чанки на феном и он на фронте не работает. Приходиться идти по ajax на сервер выбирать отдельно данные закидывать их в чанк и html уже забирать. Много лишних телодвижений. Шаблоны лучше на фронте заливать данными. По большому счету я хорошо знаком только с модекс. Другие системы смотрел, но что-то не производят они впечатления. Пару api можно быстро создать, но чтоб чисто сделать апи для 200 таблиц понадобиться год. И еще год фронт написать. Тут на работе не будут ждать 2 года, чтоб у них все заработало. Новое можно только постепенно. Сейчас неделю ночи трачу обдумывая как на основе модекс бек сделать. По идее в часов 200 в течении 2-3 месяцев можно сделать такой функционал, что потом переезд будет в разы проше чем на каком-либо другом беке.
              iWatchYouFromAfar
              18 января 2024, 14:11
              0
              Ну вы же и делаете сейчас новый фронт на Vue — соответственно на него у вас в любом случае уйдет год, не важно откуда данные приходят, с вашего сниппета или с любого другого реста.

              Значит основная проблема — бекенд. У вас API для 200 таблиц написан на MODx, где у вас все таки связаны руки. Значит перенести эту логику в условную лару не составит труда. Это же просто работа с данными которые лежат где-то в БД.

              Зачем ночами сидеть и пытаться запихать на фронт сайта, который сделан на MODx — Vue, я хз. Еще вам придется решать вопросы зависимости компонентов от jQuery.

              Ну… Это так, мысли в слух. Я не удивлен если у тебя на сайте будет и Vue и jQuery и что-то на ванильке. Франкеншейты они такие…
        Александр Туниеков
        28 декабря 2023, 22:55
        0
        Хороший вопрос :-). Сам думал. Но gtsAPI это только часов 6-12 остальное разборки с vue. Чтобы отдать чисто страницу с #app надо реализовать функионал который выдается pdoMenu и Login еще. Это еще часов 40 для реализации авторизации. Ну меню конечно роуты SPA дают не так сложно если по стандарту идти, но весь функционал за 8 лет написанный я в vue за неделю не напишу. И за года 2 не напишу наверно :-). То есть надо и меню модекс переключать и меню SPA. Что тоже сложно. Пока проще pdoMenu и Login от модекса и только подрубать часть функионала на vue на странице.
        Авторизуйтесь или зарегистрируйтесь, чтобы оставлять комментарии.
        18