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

Пока в пробке стою 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

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

Зацепил меня данный комментарий. Думал после видео что-нибудь кто-нибудь ответит, но нет)

Я ещё первое до конца не досмотрел. А второе вообще 3 часа. ))

Если мы берем за аксионму тот факт, что GraphQL это чисто JS, а проект на PHP, то реализация API потребует абсолютно другого технологического стека.

Я имел ввиду немного другое. Конечно не надо менять стеки. Я хотел сказать, что нет особой необходимости использовать GraphQL для PHP разработчиков. Если только у тебя не мега сервис с могущим API, как говорит Кирилл Несмеянов.Т.е.PHP разработчику вполне хватит REST-а.

А вот если посмотреть со стороны фронт разработчика, то ему GraphQL даёт больше плюшек. Он не знает ни схем, ни связей объектов в отличие от PHP разработчика (и любого другого бекэндера). И GraphQL даёт ему возможность самому строить запросы не зная этого.

Попробую пояснить мысль. Представим, что MODX — это сервис с API, как это изначально планировалось сделать в MODX3 — использовать Slim в качестве ядра и работать через API. Тогда можно подключать любую админку. Как мне кажется (!), тут GraphQL в качестве обёртки не нужен. Вполне хватит обычного REST-а.

П.С. Возможно, я говорю глупости. Просто ещё не до конца вкурил эту тему. :)

Посмотрел. Заинтересовало. Но… GraphQL — это как бы альтернатива REST-у. Придумана фронтэндерами. Удобно. Но в экосистеме MODX я не встречал даже какой-то толковой наработки по RESTful. Поэтому GraphQL вряд ли будет востребован разработчиками, использующими MODX. И это не удивительно. Могу ошибаться, но скорее всего и в WP, Joomla и т.п. CMS такого тоже не увидишь. Это другой уровень.
В свете сказанного, GraphQL выглядит немного неуместно для PHP. Как и для любого другого серверного языка. А вот для JS самое оно. Фронтэндеру не нужно разбираться в связях и типах. Всё прописано в схемах.
Но это, как требует говорить Николай, чисто моё мнение.

У меня было бы желание, я мог бы полностью переписать админку MODX-а, и это было бы во много раз удобней и перспективней

Без ложной скромности замечу,
Я — гениальный человек!
А то что ничего не создал…
Так я был занят и болел.
(ещё пирожков)

П.С. Извини, но мимо тёщиного дома… ))

А как насчет этого?

Ого! Шаманы, мать их.