Я бы всё-таки не стал рассматривать REST в реализации MODX. Мало того, что сам стандарт уже старый и ограниченный, так ещё и в MODX он хрен знает как поддерживается. Многие серверы по умолчанию отключают опасные методы. Как в этом случае реализовывать глаголы? Костылями как в Laravel? Есть смысл обратить внимание на JSON-API или OpenAPI, в которых решены многие проблемы REST.
По сравнению с другими у GraphQL сложнее порог входа. Нужно учить язык. JSON-API в этом плане проще. И масштабируемее. Можно начать с простого REST, а закончить сложными запросами. Есть ещё OpenAPI. В общем только выбирай.
По поводу последнй цитаты… Представляете уровень его самомнения? Он не фанат статических методов. Не нравиться, не используй. А кому то нравится. И что? Пшли на… Просто удивительно!
Этот PR завязан на того же Джейсона. Требуется его благоволение, чтобы добавил. Да ещё и вопрос куда. В третью версию — значит выбросить в пропасть. А во вторую вряд ли добавил бы.
А идея с админкой — это альтернатива, которая полностью исключает необходимость обращения к этому товарищу. Это просто обычный компонент, но не совсем обычный. ))
Современные тенденции требуют использования модных JS фреймворков. И тут я полностью выключаюсь из процесса ибо я не дизайнер, не верстальщик и у меня нет большого опыта работы с Vue/React/Angular и т.п. фреймворками. Могу чисто языком поработать ))
По моему опыту скажу, что было бы отличным решением разработать, что сейчас делает Дмитрий Лукьяненко: Evo с Laravel.
Таких как Дмитрий в лагере Revolution не нашлось. Именно поэтому и был предложен более простой вариант. Но я не уверен, что даже этот вариант сообщество потянет. Это раз.
А в третьих, что там напилит Дмитрий покажет время. И если напилит. И то что получиться, думаю, будет интересно ему и ещё троим-четверым (не в обиду Дмитрию). И пока Revo не скатилась до уровня Evo нужно принимать срочные меры. Иначе через несколько лет его постигнет судьба младшего брата.
После публикации этого поста Марк обратил внимание на мой PR (@Иван Бочкарев приложил руку) с возможностью расширения класса modX, дающий разработчикам больше контроля над ядром, ибо можно создать свой класс приложения и не ждать милости от core-разработчиков. Марк высоко оценил данную возможность.
Но вот пришел главный и поставил жирную точку. Цитата:
I am not necessarily in favor of making the modX class itself more extensible, at least not in the current architecture. We already have too much flexibility at times.
Т.е. MODX и так слишком гибкий. Харэ.
I'm concerned that encouraging extensions to the modX class would open up a whole new set of problems and make upgrade paths even more difficult.
Каким боком разработчика ядра должно касаться то, что делает пользователь MODX, самостоятельно расширяющий систему. Твоя задача дать эту возможность, а дальше не твоя забота. Но нет, ни в какую он (Джейсон) не хочет давать контроль над ядром, даже на уровне пользователя.
I'm also not a fan of using static instance methods to retrieve MODX as a dependency. Dependencies should be explicit, in my opinion.
Разработчик добавил этот метод в ядро, но пользоваться им, он считает, плохо. Хотя в том же ядре полно использований статических методов. И примеры из смежный более успешных продуктов не убедительны.
Ну что я могу сказать. Этот человек делает всё, чтобы MODX остался там, где он есть.
П.С. Какие-то странности с уровнем комментариев. Писал в корень — показывает 3 точки, хотя ссылки на parent нет.Лично я для старта выбрал Swagger, т.е. OpenAPI спецификацию. Она более читабельна, чем JSON-API.
А по API что скажешь?
А идея с админкой — это альтернатива, которая полностью исключает необходимость обращения к этому товарищу. Это просто обычный компонент, но не совсем обычный. ))
Современные тенденции требуют использования модных JS фреймворков. И тут я полностью выключаюсь из процесса ибо я не дизайнер, не верстальщик и у меня нет большого опыта работы с Vue/React/Angular и т.п. фреймворками. Могу чисто языком поработать ))
А в третьих, что там напилит Дмитрий покажет время. И если напилит. И то что получиться, думаю, будет интересно ему и ещё троим-четверым (не в обиду Дмитрию). И пока Revo не скатилась до уровня Evo нужно принимать срочные меры. Иначе через несколько лет его постигнет судьба младшего брата.
Но вот пришел главный и поставил жирную точку. Цитата:
Т.е. MODX и так слишком гибкий. Харэ.
Каким боком разработчика ядра должно касаться то, что делает пользователь MODX, самостоятельно расширяющий систему. Твоя задача дать эту возможность, а дальше не твоя забота. Но нет, ни в какую он (Джейсон) не хочет давать контроль над ядром, даже на уровне пользователя.
Разработчик добавил этот метод в ядро, но пользоваться им, он считает, плохо. Хотя в том же ядре полно использований статических методов. И примеры из смежный более успешных продуктов не убедительны.
Ну что я могу сказать. Этот человек делает всё, чтобы MODX остался там, где он есть.
И посмотри, что в лог пишется.
Как хочешь, так и понимай. Сколько лет MODX, а базового решения для апи нет. Сделать универсальное решение — большое дело. Хотя бы через компонент.