Сергей Шлоков

Задача как раз начинать не с ядра.

Вот тут и вылазит проблема завязки на специфичный бекэнд. Совместимости нет.

Главный продукт — минишоп. Начинать нужно с него.

Пока обсуждаем идею. Роудмап — следующий шаг.

Я выше написал, что вопрос один, а пример кода другой. Ответ — я же не бом бом. Ни примера вызова сниппета ничего. Лично я не знаю, чем еще помочь.

Пока в пробке стою modzone.ru/blog/2017/10/06/why-doesnt-work-tag-ignore/

Блин, во первых за рулём. А во вторых, с телефона это делать просто боль. Может вечером…

У себя в блоге я уже разбирал отличия. Кому интересно, уже разобрались. Принципы абсолбтно разные.

Ты взял и пилишь, а в этом сообществе таких героев нет (

Не путай народ сравнивая парсер и шаблонизатор. У последнего тоже есть парсер. Это как сравнивать двигатель и минивен.

Можно и для Ларки, но там другое сообщество. Это можно сделать на следующем витке развития админки. А тут сообщество, которое может поддержать это. Тут целевая аудитория в отличие от Ларки.

отлично вписывается в философию MODX.

С точностью до наоборот.

Если пилить свой RestAPI, то однозначно без xPDO. Можно взять Slim. Он изнвчвльно и планировался в MODX3. А вот с ORM вопрос дискуссионный. ActiveRecord или DataMapper? Первый вопрос. Второй — какой конкретно?

Может и так.

Вопрос а зачем MODX если делать так:

ПАТАМУШТА. ))

Странно слышать такой вопрос от человека, который не первый год пилит свою систему. Новая админка ничего не ломает и может работать параллельно со старой. А в дальнейшем, если взлетит, то следующий шаг — постепенное отвязывание от старого ядра.

Например, пилотные серии «Игры престолов» провалились.Никто не бросился делать сразу все сезоны. Было принято решение сделать всё заново с другими актерами и сценаристами. И в итоге грандиозный успех.

— RestApi, которое будет работать как бэкенд для любых админок и устанавливаться на любой свежий MODX. Api должно реализовывать текущий функционал админки MODX через её процессоры.

На первом этапе это можно пропустить и задействовать рабочие коннекторы. При работе над админкой картина будущего API станет более ясной. Тут мои знания могу пригодиться.

— VueManager, который будет ставиться и предоставлять альтернативный менеджер, работающий с этим API. Тут только frontend приложение с основным функционалом. Второй этап — продумать его расширение дополнениями. У Vue.js есть, например, система событий на которую можно подписываться и что-то делать.

А вот тут я мимо. Знания самые базовые.

И тогда мы получим свою MODX-Like CMS, которая будет работать на тех же идеях, но написанную с нуля и без тяжелого наследия времён Etomite CMS.

Абсолютли )

Задача как раз не закопаться сразу, а идти маленькими шажками. Использовать базовое ядро, а затем можно будет и дальше пойти. Сразу форк никто не потянет.

url: «assets/main/data/infra-index.json»

Откуда взялся index? Вы парсите плейсхолдер «alias», а передаете «config», в котором нет никакого index.

Ну и звёздочек у Slim на Github больше — а все знают, что это самое важное!

Двух мнений быть не может! ))

А админку какую-то готовую брал или сам пилил?

Если не секрет, почему именно Slim. Не проще было бы взять родной для Eloquent Lumen?

Ну или возьмем пример из топика. Что сделал ТС? Он подцепился к API modx.pro который разработал Василий и завернул ответ в GraphQL. И тут напрашивается резонный вопрос, а зачем нам этот промежуточный слой в виде уже существующего /assets/components/extras/action.php, если у нас есть доступ к коду и можно сразу сформировать GraphQL

Насколько я понимаю, доступа к коду как раз и нет. У него же нет другой точки входа с описанными схемами или доступа к БД напрямую. Поэтому и пришлось юзать что дали. Или есть? )

И одна из них webonyx/graphql-php взята за основу для Railt

Хотя сам Кирилл её не хвалит )