AdminRevolution. Быть или не быть?
Привет, друзья!
Есть тема для дискуссии. Как вы знаете, дела в лагере разработчиков MODX не очень. Если глянуть на список пользователей, то многие из топа уже покинули этот лагерь. Недавно сообщество потеряло главного амбассадора. Да и номер первый, как мы знаем, с MODX контактирует только на старых проектах. Конечно это удручает. Но такова жизнь. Так происходит везде. Это не ноу-хау MODX. Рынок разработки стремительно меняется. Приходят новые технологии, языки, подходы. Сайты становятся сложнее. Рынок простых CMS сужается. Конкуренция становиться жёстче. И тут MODX сильно проигрывает. Несмотря на то, что он не хуже Вордпресса, Джумлы и Битрикса, новых разработчиков он привлекает всё меньше и меньше. И это самое плохое. Старые и опытные разработчики будут уходить какую бы супер-пупер систему вы не сделали, а вот новых привлечь — задача наиважнейшая.
Нужно заниматься популяризацией и продвижением. Митапы, статьи на популярных ресурсах (Хабр, Медиум и т.п.), следовать в тренде web разработки. Ещё один из важных моментов — нужные дополнения. Судя по вопросам половина кейсов (в России) — это miniShop и всё, что с ним связано. Т.е. хорошие решения тоже популяризируют MODX.
Многие приводят в пример YII. В тяжёлые для него времена нашлись энтузиасты и подхватили падающий флаг. У MODX они тоже есть. Но, к сожалению, самым узким местом является команда core-разработчиков. Они уже не у одного энтузиаста сбили желание хоть что-то сделать для MODX. Я попробовал в мягком режиме обойти эту проблему и предложил решение с расширением главного класса (тут и тут). Но чуда не случилось. Джейсон отмёл данный вариант не объясняя причин. Патамушта.
Но есть ещё один вариант, который не требует никаких разрешений и одобрений со стороны этих «собак на сене». Нет, не форкнуть. Реализовать свою админку. Например, на том же VueJS. Представляю как многие ухмыльнулись. Да, это может помочь. Поясню. Как вы знаете (а я обращаюсь именно к опытным разработчикам), у админки своя точка входа в отличие от фреймворков. Также как и у WP, Joomla. Поэтому ничто не мешает сделать ещё одну. Всё это можно сделать в виде компонента. Ну или того же Composer. Она будет также через коннекторы работать с ядром. И в ней реализовать все самые любимые фишки MODX. А главное — избавить новичков от страха учить ExtJS. ))
Я знаю, что многие из вас скажут. Да, это много работы. Но я уверен, что за тот же год активной работы нашей группы над MODX3, (который, я уверен, никогда не выйдет) можно было бы сделать более менее рабочее решение. И тут я хочу высказать крамольную идею. Необходимо изменить подход. Не разрабатывать в админке бекэнд для дополнений. Всё это нужно вынести на фронт, как это делают для фреймворков. И тут можно применить любые технологии. Оставить только вещи типа настроек, прав, работы с контентом и дополнениями. Да и для контент-менеджеров можно свой интерфейс сделать. Т.е. админка только для администраторов. Это существенно упрощает задачу.
Но всё это упирается в один самый важный вопрос — что делать с существующими дополнениями? У меня только один ответ — переделывать. Я, например, готов. И даже больше скажу, хочу. Сделать такое дополнение, которое можно будет поставить и на MODX и на Ларавел. Я знаю, есть люди поумнее меня. Может они найдут более компромиссное решение. Тут всё упирается не только в желание, но и возможности.
Вот такая тема. Без технических подробностей и конкретных решений. Просто «для подумать». Возможно это даст толчок другой идее. Может быть дело дойдёт до прототипа. А там и корифеи подтянутся со своими знаниями и предложениями.
Update 17.09.2019
Демо прототипа.
Есть тема для дискуссии. Как вы знаете, дела в лагере разработчиков MODX не очень. Если глянуть на список пользователей, то многие из топа уже покинули этот лагерь. Недавно сообщество потеряло главного амбассадора. Да и номер первый, как мы знаем, с MODX контактирует только на старых проектах. Конечно это удручает. Но такова жизнь. Так происходит везде. Это не ноу-хау MODX. Рынок разработки стремительно меняется. Приходят новые технологии, языки, подходы. Сайты становятся сложнее. Рынок простых CMS сужается. Конкуренция становиться жёстче. И тут MODX сильно проигрывает. Несмотря на то, что он не хуже Вордпресса, Джумлы и Битрикса, новых разработчиков он привлекает всё меньше и меньше. И это самое плохое. Старые и опытные разработчики будут уходить какую бы супер-пупер систему вы не сделали, а вот новых привлечь — задача наиважнейшая.
Нужно заниматься популяризацией и продвижением. Митапы, статьи на популярных ресурсах (Хабр, Медиум и т.п.), следовать в тренде web разработки. Ещё один из важных моментов — нужные дополнения. Судя по вопросам половина кейсов (в России) — это miniShop и всё, что с ним связано. Т.е. хорошие решения тоже популяризируют MODX.
Многие приводят в пример YII. В тяжёлые для него времена нашлись энтузиасты и подхватили падающий флаг. У MODX они тоже есть. Но, к сожалению, самым узким местом является команда core-разработчиков. Они уже не у одного энтузиаста сбили желание хоть что-то сделать для MODX. Я попробовал в мягком режиме обойти эту проблему и предложил решение с расширением главного класса (тут и тут). Но чуда не случилось. Джейсон отмёл данный вариант не объясняя причин. Патамушта.
Но есть ещё один вариант, который не требует никаких разрешений и одобрений со стороны этих «собак на сене». Нет, не форкнуть. Реализовать свою админку. Например, на том же VueJS. Представляю как многие ухмыльнулись. Да, это может помочь. Поясню. Как вы знаете (а я обращаюсь именно к опытным разработчикам), у админки своя точка входа в отличие от фреймворков. Также как и у WP, Joomla. Поэтому ничто не мешает сделать ещё одну. Всё это можно сделать в виде компонента. Ну или того же Composer. Она будет также через коннекторы работать с ядром. И в ней реализовать все самые любимые фишки MODX. А главное — избавить новичков от страха учить ExtJS. ))
Я знаю, что многие из вас скажут. Да, это много работы. Но я уверен, что за тот же год активной работы нашей группы над MODX3, (который, я уверен, никогда не выйдет) можно было бы сделать более менее рабочее решение. И тут я хочу высказать крамольную идею. Необходимо изменить подход. Не разрабатывать в админке бекэнд для дополнений. Всё это нужно вынести на фронт, как это делают для фреймворков. И тут можно применить любые технологии. Оставить только вещи типа настроек, прав, работы с контентом и дополнениями. Да и для контент-менеджеров можно свой интерфейс сделать. Т.е. админка только для администраторов. Это существенно упрощает задачу.
Но всё это упирается в один самый важный вопрос — что делать с существующими дополнениями? У меня только один ответ — переделывать. Я, например, готов. И даже больше скажу, хочу. Сделать такое дополнение, которое можно будет поставить и на MODX и на Ларавел. Я знаю, есть люди поумнее меня. Может они найдут более компромиссное решение. Тут всё упирается не только в желание, но и возможности.
Вот такая тема. Без технических подробностей и конкретных решений. Просто «для подумать». Возможно это даст толчок другой идее. Может быть дело дойдёт до прототипа. А там и корифеи подтянутся со своими знаниями и предложениями.
Update 17.09.2019
Демо прототипа.
Поблагодарить автора
Отправить деньги
Комментарии: 148
Думаю в таком случае этим можно заняться именно форканув проект.
Смысл делать такие фундаментальные правки раздельно от MODX ядра?
Смысл делать такие фундаментальные правки раздельно от MODX ядра?
Задача как раз не закопаться сразу, а идти маленькими шажками. Использовать базовое ядро, а затем можно будет и дальше пойти. Сразу форк никто не потянет.
Маленькими шажками:
— Релиз MODX 3 уже 2 года ждут
— Релиз EVO 2 уже год ждут
Форк есть смысл делать только ради того что б уйти от MODX LLC и их последнего слова что и как делать.
Но скажу я вам что без имени MODX будет сразу куча работы в плане маркетинга ибо обьяснить что это тот же MODX но называется теперь по другому будет крайне сложно и на это нужно много ресурсов.
Поэтому как по мне логичней организовывать сообщество и продавливать MODX LLC.
— Релиз MODX 3 уже 2 года ждут
— Релиз EVO 2 уже год ждут
Форк есть смысл делать только ради того что б уйти от MODX LLC и их последнего слова что и как делать.
Но скажу я вам что без имени MODX будет сразу куча работы в плане маркетинга ибо обьяснить что это тот же MODX но называется теперь по другому будет крайне сложно и на это нужно много ресурсов.
Поэтому как по мне логичней организовывать сообщество и продавливать MODX LLC.
Всё равно задумываемся об форке (пониманию что речь не о нём), как бы не пытались убежать от этих мыслей.
Идея шикарная. Хоть я и не «профессиональный разработчик», но готов помочь тестированием/отладкой/вёрсткой/временем.
Отдельное спасибо за выражение в сторону core-разработчиков:
Идея шикарная. Хоть я и не «профессиональный разработчик», но готов помочь тестированием/отладкой/вёрсткой/временем.
Отдельное спасибо за выражение в сторону core-разработчиков:
«собак на сене»Грустно посмеялся.
На мой взгляд — это единственный реальный вариант.
Нужно 2 дополнения для MODX:
— RestApi, которое будет работать как бэкенд для любых админок и устанавливаться на любой свежий MODX. Api должно реализовывать текущий функционал админки MODX через её процессоры.
Я уже делал что-то подобное для своего мобильного приложения, хоть это и не Rest. Можно посмотреть, ради интереса, только не берите за основу.
Внимание, сам RestApi не обязательно писать на MODX, он должен просто работать с MODX, но базироваться может хоть на Slim3 + Eloquent, если разработчикам так удобнее.
— VueManager, который будет ставиться и предоставлять альтернативный менеджер, работающий с этим API. Тут только frontend приложение с основным функционалом. Второй этап — продумать его расширение дополнениями. У Vue.js есть, например, система событий на которую можно подписываться и что-то делать.
С самого начала нужно писать тесты и документировать API (это можно делать и автоматически). Тогда это не просто взлетит, а придаст второе дыхание системе. Любители React.js смогут написать свою админку — Api-то общий и понятный.
При таком подходе, над дополнениями могут работать 2 независимых команды. Кому-то по душе бэкенд, кому-то фронтенд.
Дальше очередь за дополнениями. Некоторые будут работать со старой админкой, некоторые — с новыми, это уже на совести их авторов. Пусть победит сильнейший!
Ну а в очень дальнем будущем, RestApi можно будет и вовсе отвязать от MODX и использовать с каким-то другим ядром. Потому что это Api является уровнем абстракции, под которым можно заменить что угодно — и фронтенд об этом не узнает.
И тогда мы получим свою MODX-Like CMS, которая будет работать на тех же идеях, но написанную с нуля и без тяжелого наследия времён Etomite CMS.
Нужно 2 дополнения для MODX:
— RestApi, которое будет работать как бэкенд для любых админок и устанавливаться на любой свежий MODX. Api должно реализовывать текущий функционал админки MODX через её процессоры.
Я уже делал что-то подобное для своего мобильного приложения, хоть это и не Rest. Можно посмотреть, ради интереса, только не берите за основу.
Внимание, сам RestApi не обязательно писать на MODX, он должен просто работать с MODX, но базироваться может хоть на Slim3 + Eloquent, если разработчикам так удобнее.
— VueManager, который будет ставиться и предоставлять альтернативный менеджер, работающий с этим API. Тут только frontend приложение с основным функционалом. Второй этап — продумать его расширение дополнениями. У Vue.js есть, например, система событий на которую можно подписываться и что-то делать.
С самого начала нужно писать тесты и документировать API (это можно делать и автоматически). Тогда это не просто взлетит, а придаст второе дыхание системе. Любители React.js смогут написать свою админку — Api-то общий и понятный.
При таком подходе, над дополнениями могут работать 2 независимых команды. Кому-то по душе бэкенд, кому-то фронтенд.
Дальше очередь за дополнениями. Некоторые будут работать со старой админкой, некоторые — с новыми, это уже на совести их авторов. Пусть победит сильнейший!
Ну а в очень дальнем будущем, RestApi можно будет и вовсе отвязать от MODX и использовать с каким-то другим ядром. Потому что это Api является уровнем абстракции, под которым можно заменить что угодно — и фронтенд об этом не узнает.
И тогда мы получим свою MODX-Like CMS, которая будет работать на тех же идеях, но написанную с нуля и без тяжелого наследия времён Etomite CMS.
— RestApi, которое будет работать как бэкенд для любых админок и устанавливаться на любой свежий MODX. Api должно реализовывать текущий функционал админки MODX через её процессоры.На первом этапе это можно пропустить и задействовать рабочие коннекторы. При работе над админкой картина будущего API станет более ясной. Тут мои знания могу пригодиться.
— VueManager, который будет ставиться и предоставлять альтернативный менеджер, работающий с этим API. Тут только frontend приложение с основным функционалом. Второй этап — продумать его расширение дополнениями. У Vue.js есть, например, система событий на которую можно подписываться и что-то делать.А вот тут я мимо. Знания самые базовые.
И тогда мы получим свою MODX-Like CMS, которая будет работать на тех же идеях, но написанную с нуля и без тяжелого наследия времён Etomite CMS.Абсолютли )
На первом этапе это можно пропустить и задействовать рабочие коннекторы.Не соглашусь, API здесь первично.
Если работать с тем, что есть — у нас опять будут разные костыли, потому что нынешние процессоры завязаны на нынешнюю админку и от этого нужно избавиться. Плюс, автоматическая генерация документации будет возможна только по новому API.
А вот как появится такое API (хотя-бы для работы хоть с чем-то простым), тогда можно начинать и фронтенд. Дальше обновляется API и за ним идёт админка.
В моём представлении — вот так.
Может и так.
Если пилить свой RestAPI, то однозначно без xPDO. Можно взять Slim. Он изнвчвльно и планировался в MODX3. А вот с ORM вопрос дискуссионный. ActiveRecord или DataMapper? Первый вопрос. Второй — какой конкретно?
Я думаю, эти вопросы решит тот, кто начнёт делать RestApi дополнение.
Можно долго обсуждать и принимать решения, но пока у проекта не появится паровозик, который его потащит — проект никуда и не поедет.
На данный момент, насколько я понимаю, никакая ORM вообще не нужна, потому что мы будем работать с готовыми объектами и процессорами MODX, делая к ним запросы, получая ответ, обрабатывая и отдавая в чистом виде наружу.
RestApi — это просто слой абстракции над ядром MODX со всеми его сущностями.
Объекты MODX работают через xPDO, никуда от него не денешься. Не писать же сразу все свои modResource, modDocument и т.д. с их логикой — это уже точно не поднять.
Можно долго обсуждать и принимать решения, но пока у проекта не появится паровозик, который его потащит — проект никуда и не поедет.
На данный момент, насколько я понимаю, никакая ORM вообще не нужна, потому что мы будем работать с готовыми объектами и процессорами MODX, делая к ним запросы, получая ответ, обрабатывая и отдавая в чистом виде наружу.
RestApi — это просто слой абстракции над ядром MODX со всеми его сущностями.
Объекты MODX работают через xPDO, никуда от него не денешься. Не писать же сразу все свои modResource, modDocument и т.д. с их логикой — это уже точно не поднять.
Ребят я с вами в огонь и в воду =).
Но с кодом ссори пока не помогу. Все, что нужно обращайтесь.
Но с кодом ссори пока не помогу. Все, что нужно обращайтесь.
Вопрос а зачем MODX если делать так:
если же делать совсем по уму и все через REST то прийдем к тому что можно будет и бек менять и фронт, главное что было API Френдли.
Сейчас пилю Evo 2.0 на базе компонентов Laravel, но в перспективе смотрю в сторону как раз такого решения.
Да понятно что потеряем обратную совместимость но получим современный удобный инструмент.
Ибо на текущий момент:
REVO — нужно потратить очень много времени что б переписать систему и тонну дополнений что б привести все в норму и соответствия текущим трендам.
EVO — ближе по коду к текущим трендам но большие печали по маркетплейсу.
Я бы предложил перевести разговор в плоскость что нас держит в философии MODX и что нужно перенести на свежие рельсы.
Внимание, сам RestApi не обязательно писать на MODX, он должен просто работать с MODX, но базироваться может хоть на Slim3 + Eloquent, если разработчикам так удобнее.
Как по мне стоит просто сделать MODX-Like Admin Panel на базе одного из популярных фреймворков. если же делать совсем по уму и все через REST то прийдем к тому что можно будет и бек менять и фронт, главное что было API Френдли.
Сейчас пилю Evo 2.0 на базе компонентов Laravel, но в перспективе смотрю в сторону как раз такого решения.
Да понятно что потеряем обратную совместимость но получим современный удобный инструмент.
Ибо на текущий момент:
REVO — нужно потратить очень много времени что б переписать систему и тонну дополнений что б привести все в норму и соответствия текущим трендам.
EVO — ближе по коду к текущим трендам но большие печали по маркетплейсу.
Я бы предложил перевести разговор в плоскость что нас держит в философии MODX и что нужно перенести на свежие рельсы.
Вопрос а зачем MODX если делать так:ПАТАМУШТА. ))
Странно слышать такой вопрос от человека, который не первый год пилит свою систему. Новая админка ничего не ломает и может работать параллельно со старой. А в дальнейшем, если взлетит, то следующий шаг — постепенное отвязывание от старого ядра.
Например, пилотные серии «Игры престолов» провалились.Никто не бросился делать сразу все сезоны. Было принято решение сделать всё заново с другими актерами и сценаристами. И в итоге грандиозный успех.
Ну так вот потому что долгое время и пилю систему то и задаю такие вопросы:) Как по мне ничего странного в этом нет. Мир развивается притом очень быстро. Так же я вот сейчас внедрил MVC в EVO но в сообществе дай бог 5 человек оценило остальные подняли кипишь мол как же так хотим по старому.
Да и то что хорошие специалисты уходят а не помогают развивать систему тоже говорит что есть проблемы.
Вообщем я за то что б открыто обсудить проблемы и варианты. А один из вариантов и есть MODX-Like Admin Panel for Laravel(или любой другой фреймворк).
Да и то что хорошие специалисты уходят а не помогают развивать систему тоже говорит что есть проблемы.
Вообщем я за то что б открыто обсудить проблемы и варианты. А один из вариантов и есть MODX-Like Admin Panel for Laravel(или любой другой фреймворк).
Можно и для Ларки, но там другое сообщество. Это можно сделать на следующем витке развития админки. А тут сообщество, которое может поддержать это. Тут целевая аудитория в отличие от Ларки.
Вопрос а зачем MODX если делать такЗатем, чтобы не распугать всё сообщество и не переименовывать modx.pro
А если серьёзно — такой подход ничем никого не обязывает и ни к чему не привязывает. Учитывая, как обстоят дела с финансированием и свободным временем у разработчиков — это единственный, на мой взгляд, реальный вариант хоть что-то сделать.
Выкинуть MODX никогда не поздно, но не нужно это делать в самом начале.
Я тут больше про то что нужно определиться в чем суть философии MODX. И отталкиваться от этих принципов.
Для примера я долгое время считал что MODX Parser очень крут и удобен и что это и есть ядро MODX но на деле FENOM(в REVO) и BLADE, TWIG(в EVO) куда удобней стандартного парсера и отлично вписывается в философию MODX.
Для примера я долгое время считал что MODX Parser очень крут и удобен и что это и есть ядро MODX но на деле FENOM(в REVO) и BLADE, TWIG(в EVO) куда удобней стандартного парсера и отлично вписывается в философию MODX.
отлично вписывается в философию MODX.С точностью до наоборот.
Я к EVO прикрутил еще и контроллеры :) получилось очень удобно, надеюсь скоро запишу видео и покажу как это все работает.
А самое интересно что получилось это все совместить:
— хочешь стандартный парсер да не вопрос
— хочешь шаблонизатор и в нем снипеты да тоже не вопрос
— хочешь что б в шаблонизаторе не было сниппетов(выносим их в контроллер) тоже не вопрос
p.s. Рекомендую потратить время и вникнуть в соседние технологии и понять в чем плюсы и отличия парсера и стороннего шаблонизатора:) Ведь понять что лучше для чего можно только сравнив.
А самое интересно что получилось это все совместить:
— хочешь стандартный парсер да не вопрос
— хочешь шаблонизатор и в нем снипеты да тоже не вопрос
— хочешь что б в шаблонизаторе не было сниппетов(выносим их в контроллер) тоже не вопрос
p.s. Рекомендую потратить время и вникнуть в соседние технологии и понять в чем плюсы и отличия парсера и стороннего шаблонизатора:) Ведь понять что лучше для чего можно только сравнив.
Не путай народ сравнивая парсер и шаблонизатор. У последнего тоже есть парсер. Это как сравнивать двигатель и минивен.
Ок тогда более правильней будет:
— MODX Шаблонизатор
— Fenom Шаблонизатор
— MODX Шаблонизатор
— Fenom Шаблонизатор
У себя в блоге я уже разбирал отличия. Кому интересно, уже разобрались. Принципы абсолбтно разные.
Кинь ссылочку почитать
Блин, во первых за рулём. А во вторых, с телефона это делать просто боль. Может вечером…
Спасибо не горит :)
Пока в пробке стою modzone.ru/blog/2017/10/06/why-doesnt-work-tag-ignore/
Ты взял и пилишь, а в этом сообществе таких героев нет (
это уже на совести их авторовтут бы придусмотреть такой вариант, чтобы не только автору можно было адаптировать дополнение под API, а и самому разработчику сайта, например, я не думаю, что тотже автор MIGX сразу обновит дополнение, а своими силами почему бы и не адаптировать)))
Так это проще всего. это ж opensource заходишь в репозиторий проекта адаптируешь и отправляешь пулл реквест. На крайняк если автор потерялся то делаешь форк репозитория
На столько не смог оставаться безучастным, что даже восстановил аккаунт (давно покинул ряды активистов MODX, посвятив себя фронтенду, но продолжаю поддерживать старые проекты)…
Я верю в это сообщество, но, думаю, что правильный путь выбрать будет очень непросто. Некоторые решения (REST-расширение, например) вполне очевидны, но вот выбранная архитектура может больно «аукнуться» позже. Трендовые решения (React/Vue/Angular/Ember) дают быстрый старт, но имеют пару фатальных недостатков — они «смертны» (да, Реакт и Вью через 3 года станут жуткими архаизмами или на столько видоизменятся, что будут иметь мало общего с тем, что вы видите сейчас) и однонаправленны — выбирая архитектуру под React, мы практически полностью (ну или в большей степени) делаем её несовместимой с Angular/<ваш любимый фреймворк>.
Я не смею предлагать, но вижу наиболее сильный формат в поиске решений — дебаты. Т. е. должен возникнуть положительный конфликт, когда все заинтересованные стороны (а не один разработчик) принимают решение о векторе (или закладывают точку для ветвления/масштабирования). Своего рода роадмап, но не решений, а обсуждений: RestAPI — на каком языке (может, это вообще микросервис на Go или SaaS-платформа)? Какой API-фреймворк? Работа через API MODX или напрямую с БД? Типизация? Валидация? SDK? Админка — а что на счёт Headless CMS? Может, какой-то DSL для обратной совместимости? React/Vue/Angular/etc? Монорепозиторий (lerna + yarn workspace) или независимые компоненты?. Плюс такого подхода ещё и в том, что параллельно с доводами в пользу своего решения «кандидат» сам будет заинтересован в наибольшей понятности своего предложения. И сразу понятно, какие компоненты системы могут кем курироваться. Стабильно в течение какого-то времени (неделя? месяц?) «комитет» принимает решение (после того, как споры вокруг какой-то темы стабилизировались (утихли или разделилился на несколько лагерей).
Со своей стороны предлагаю опыт в клиентской и серверной шаблонизации, DSL, SSR, сборщиках, компонентном подходе и вёрстке, UX/UI.
Я верю в это сообщество, но, думаю, что правильный путь выбрать будет очень непросто. Некоторые решения (REST-расширение, например) вполне очевидны, но вот выбранная архитектура может больно «аукнуться» позже. Трендовые решения (React/Vue/Angular/Ember) дают быстрый старт, но имеют пару фатальных недостатков — они «смертны» (да, Реакт и Вью через 3 года станут жуткими архаизмами или на столько видоизменятся, что будут иметь мало общего с тем, что вы видите сейчас) и однонаправленны — выбирая архитектуру под React, мы практически полностью (ну или в большей степени) делаем её несовместимой с Angular/<ваш любимый фреймворк>.
Я не смею предлагать, но вижу наиболее сильный формат в поиске решений — дебаты. Т. е. должен возникнуть положительный конфликт, когда все заинтересованные стороны (а не один разработчик) принимают решение о векторе (или закладывают точку для ветвления/масштабирования). Своего рода роадмап, но не решений, а обсуждений: RestAPI — на каком языке (может, это вообще микросервис на Go или SaaS-платформа)? Какой API-фреймворк? Работа через API MODX или напрямую с БД? Типизация? Валидация? SDK? Админка — а что на счёт Headless CMS? Может, какой-то DSL для обратной совместимости? React/Vue/Angular/etc? Монорепозиторий (lerna + yarn workspace) или независимые компоненты?. Плюс такого подхода ещё и в том, что параллельно с доводами в пользу своего решения «кандидат» сам будет заинтересован в наибольшей понятности своего предложения. И сразу понятно, какие компоненты системы могут кем курироваться. Стабильно в течение какого-то времени (неделя? месяц?) «комитет» принимает решение (после того, как споры вокруг какой-то темы стабилизировались (утихли или разделилился на несколько лагерей).
Со своей стороны предлагаю опыт в клиентской и серверной шаблонизации, DSL, SSR, сборщиках, компонентном подходе и вёрстке, UX/UI.
Вот пришел, наговорил кучу непонятных читателям слов и довольный еще не два года свалил.
О том и речь — нужно сократить информационный разрыв. Паровоз фронтенда на столько технологически ускакал вперёд, что и привело к подобной ситуации депопуляризации MODX — потребности клиентов растут быстрее, т. к. предложений на рынке веб-дева более чем достаточно. Как я уже сказал, я готов это всё объяснять и популяризировать, если в формате видеоконференций (типа AskMeAnything Ильи Климова) или лайт-толков на живых встречах (если вы из Питера).
Привет. Как насчет принять участие в ближайшем MAB?
Не проблема, но с англоязычной аудиторией MODX могу общаться только в формате дринкапа — языковой барьер не позволяет. Ну и я определённо не смогу посвящать этому своё основное время — MODX у меня вообще не стоит в планах разработки.
На самом деле никуда паровоз фронтенда не ускакал. Это иллюзия фронтенд разработчиков и какая-то пагубная привычка каждые пол года что-то переделывать.
Возьмём Vue.
Двунаправленный биндинг? Но он существует еще со времен Backbone.
Шаблонизация? Но это было еще в Mustache и есть даже в ExtJS Modx.
Компоненты? Ну каждый их реализовывал как хотел, а история с инкапсуляцией компонентов/виджетов/отдельных частей интерфейса/назови как хочешь — оочень бородатая. БЭМ — тому свидетельство.
Vuex — как единое место хранения данных? Это всё тот же Storage из ExtJS, но чуток переработанный.
Все это было 10-15 лет назад и концептуально, ну вообще никак не поменялось.
Взять инструменты сборки.
Почти всё, что есть сейчас было еще в первых версиях Ruby on Rails. Многое: склейка спрайтов, склейка JS, переменные в CSS и т.п. не нужно нынче, т.к. стало частью стандарта или неактуально с приходом http2. А концептуально ноги инструментов сборки растут из бородатого Make, 1977 года рождения. C Babel — больше вреда чем пользы: дополнительное звено в разработке и увеличивает бандл полифилами и страдает время сборки. А что даёт? Возможность использовать самые-самые последние, «синтаксически сахарные» в большинстве своём, конструкции языка? А раньше то как жили? Простенько, банально не использовали, пока поддержка этих конструкций в браузерах не достигала 90%.
Бесспорно движение во фронтэнде есть, но технологически никуда не ускакал, а вполне себе итерационно развивается, ровно как и всё остальное.
Возьмём Vue.
Двунаправленный биндинг? Но он существует еще со времен Backbone.
Шаблонизация? Но это было еще в Mustache и есть даже в ExtJS Modx.
Компоненты? Ну каждый их реализовывал как хотел, а история с инкапсуляцией компонентов/виджетов/отдельных частей интерфейса/назови как хочешь — оочень бородатая. БЭМ — тому свидетельство.
Vuex — как единое место хранения данных? Это всё тот же Storage из ExtJS, но чуток переработанный.
Все это было 10-15 лет назад и концептуально, ну вообще никак не поменялось.
Взять инструменты сборки.
Почти всё, что есть сейчас было еще в первых версиях Ruby on Rails. Многое: склейка спрайтов, склейка JS, переменные в CSS и т.п. не нужно нынче, т.к. стало частью стандарта или неактуально с приходом http2. А концептуально ноги инструментов сборки растут из бородатого Make, 1977 года рождения. C Babel — больше вреда чем пользы: дополнительное звено в разработке и увеличивает бандл полифилами и страдает время сборки. А что даёт? Возможность использовать самые-самые последние, «синтаксически сахарные» в большинстве своём, конструкции языка? А раньше то как жили? Простенько, банально не использовали, пока поддержка этих конструкций в браузерах не достигала 90%.
Бесспорно движение во фронтэнде есть, но технологически никуда не ускакал, а вполне себе итерационно развивается, ровно как и всё остальное.
Речь не про новые плагины для красивых галерей или генераторы формочек. Я о том, что, решая какую-то задачу, разработчик оперирует инструментами, которые оптимизируют его время: можно продолжать писать статичный HTML, вручную расставлять CSS-префиксы, писать jQuery-«простыни», но если бы старых подходов хватало бы для современных требований бизнеса, ни один новый инструмент не появился бы.
Веб-воркеры, сервис-воркеры, сокеты, модули, PWA, работа в оффлайне и т. д. — всё то, что будет иметь каждый конкурентный продукт в ближайшие годы. Конечно, все эти технологии не должны навязываться выбранной CMS/CMF-системой, но ещё хуже, когда они противоречат.
Восстребованной будет та система, которая минимизирует время + ошибки + порог вхождения + тестирование и отладку + кастомизацию и/или расширяемость. Я использовал MODX, когда для этих условий не было аналогов, но это время прошло. Быть разработчиком и не развиваться — значит, быть плохим разработчиком.
Веб-воркеры, сервис-воркеры, сокеты, модули, PWA, работа в оффлайне и т. д. — всё то, что будет иметь каждый конкурентный продукт в ближайшие годы. Конечно, все эти технологии не должны навязываться выбранной CMS/CMF-системой, но ещё хуже, когда они противоречат.
Восстребованной будет та система, которая минимизирует время + ошибки + порог вхождения + тестирование и отладку + кастомизацию и/или расширяемость. Я использовал MODX, когда для этих условий не было аналогов, но это время прошло. Быть разработчиком и не развиваться — значит, быть плохим разработчиком.
Компоненты? Ну каждый их реализовывал как хотелДак в этом и была большая проблема, в том числе.
Шаблонизация? Но это было еще в Mustache и есть даже в ExtJS Modx.Вы явно не понимаете о чём говорите) Действительно, зачем этот vue вообще нужен, когда есть лодашевый _.template()? Всего одна маленькая функция для шаблонизации! Не ну а чо, берём её, придумываем свою реализацию компонентов и вперёд пилить интерфейсы)
Vuex — как единое место хранения данных? Это всё тот же Storage из ExtJS, но чуток переработанный.Чуток?) Я вам по секрету покажу:
window.Store = {};
вот и всё, что нужно для глобального хранилища данных. И чего они там в своих MobX'ах и Vuex'ах всё усложняют?)
склейка JSНынче важна не склейка js в один большой мегафайл, а наоборот — модульность и асинхронная загрузка только того, что действительно необходимо в данный момент времени на данной странице (code splitting и вот это всё).
Многое: склейка спрайтов, склейка JS, переменные в CSS и т.п. не нужно нынче, т.к. стало частью стандарта или неактуально с приходом http2И действительно, чего это все до сих пор парятся с svg-спрайтами — подключали бы на страницу по одному, делов-то.
C Babel — больше вреда чем пользы: дополнительное звено в разработке и увеличивает бандл полифилами и страдает время сборки.> страдает время сборки
SSD реально решает эту проблему. Но в современном фронтенде самую жирную часть времени сборки отнимает SCSS (который, внезапно, пришёл из руби-мира). Тут могу только посоветовать на стилус переходить.
> больше вреда чем пользы: дополнительное звено в разработке
Вы это дополнительное звено никак не почувствуете. А вообще, js — это дополнительно звено в разработке между пикселями на экране и машинным кодом, php — это дополнительное звено в разработке между http-запросом и тем же самым машинным кодом на сервере. Продолжать, думаю не стоит)
И касательно babel'я. Babel же в сути своей — прекрасен! Вы только вдумайтесь — это тулза, написанная на javascript, которая делает javascript из javascript! Это же просто волшебно)
> увеличивает бандл полифилами
Дак ему за это просто нижайший поклон! Вы действительно не видите преимущества в том, чтобы один раз написать код, который будет работать максимально везде?
А что даёт? Возможность использовать самые-самые последние, «синтаксически сахарные» в большинстве своём, конструкции языка? А раньше то как жили?Вы действительно не видите преимущества в том, чтобы писать максимально читаемый и понятный другим разработчикам код, который будет работать везде?
> А раньше то как жили?
Раньше мы писали килотонны лапши:
function () {
var argsArr = Array.prototype.slice.call(arguments);
// do something
}
Тяжёлое наследие, что поделать. Зато сейчас просто и понятно:
(...args) => { /* do something */ }
Это ведь не просто сахарок — это банально ускоряет разработку, повышает читаемость, сокращает количество набираемого кода. Нахрена писать Object.assign({}, obj), если можно написать { ...obj }? Но при этом object-rest-spread ещё только в черновиках стандарта и не имеет поддержки даже в последнем v8, а я уже без него жить не могу, потому что пишу так 5-6 дней в неделю на протяжении последних 2-3 лет.
банально не использовали, пока поддержка этих конструкций в браузерах не достигала 90%.И мне не пришлось ждать 3-4-5-6 лет, пока эта фича появится в 90% браузеров и платформ. Это же круто, чёрт побери!
Я даже на последней ноде, когда делаю бэкенд, юзаю babel. Просто именно поэтому.
И как заметил Роман выше — речь не про новые плагины галереек. Типа, ну накуя оно всё это нужно, если раньше галерейки работали без вот этого вот всего?!
Просто то количество бизнес-логики, которое сейчас приходится писать во фронтенде — несоизмеримо в разы больше, чем раньше. Вот просто в разы. И если бы сейчас не было Vue — я бы повесился писать всё это на jQuery/Backbone/Ember'е/ExtJS'е. Конечно и раньше были большие и сложные проекты — я ж не отрицаю. Но 6-7 лет назад для этого требовался штат из десятков JS-разработчиков (просто потому что кода надо было писать в десятки раз больше). То сейчас командой в 3-5 человек можно поднимать сопоставимые по уровню проекты за приемлемое время и деньги. Более того, в такую команду гораздо легче добавить новых разработчиков — они быстрее въезжают, ведь гораздо меньше кода для изучения и в нём используются уже общепринятые концепции, а не выдумывались какие-то свои.
Ну и по всем пунктам присоединяюсь к комментарию Романа выше.
Вопрос поднят очень интересный и неудивительно, что к нему оставлено ОЧЕНЬ много комментариев. Может кто-нибудь в ответ скинуть к чему пришли в итоге?
Недавно тоже задумывался сделать простенькую админку для менеджеров, в результате задумался о проблеме кастомных тв, и страниц администрирования созданных дополнениями. Возникла такая идея, возможно она мегакостыльно звучит, но всёже, vuejs хорошо работает в связке с другими js библиотеками, с темже jquery например, что если не отказываться от extjs, а оставить возможным работу с дополнениями написанными на нем, а уже для новых дополнений делать некую поддержку выноса на фронт, как предложил Сергей. В таком случае можно и развивать дополнения и оставить поддержку на первых началах стандартной админки.
В любом случае все варианты будут сводится к неким костылям, так что тут либо выбрать самый красивый костыль, либо форкнуть и развивать своими силами.
В любом случае все варианты будут сводится к неким костылям, так что тут либо выбрать самый красивый костыль, либо форкнуть и развивать своими силами.
Обратная совместимость с костылями — именно то, что завело нас в текущую ситуацию.
Это да, притом чем больше внимания обратной совместимости тем больше вопросов и проблем. В итоге качество страдает:(
Соглашусь. Не нужна обратная совместимость. Это не Enterprise. Такое может себе позволить условный Битрикс.
Evo похоронили, мир не рухнул.
Evo похоронили, мир не рухнул.
Вот это мне по душе. Я в деле. Готов тратить время на PR, тесты, допил компонентов и прочее. Нужен какой то roadMap с шагами чего делать.
Пока обсуждаем идею. Роудмап — следующий шаг.
Ядро без дополнений, которые помогут довести его до продукта никому не нужно. Ресурсов для написания дополнений надо не меньше. Самые необходимые должны быть бесплатно.
Где найти столько желающих потратить своё время за ноль рублей?
Где найти столько желающих потратить своё время за ноль рублей?
Вот тут и вылазит проблема завязки на специфичный бекэнд. Совместимости нет.
Главный продукт — минишоп. Начинать нужно с него.
Главный продукт — минишоп. Начинать нужно с него.
Главный продукт pdoTools. Без него никуда. И для многих проектов его достаточно.
Он не завязан на бекэнд. Поэтому с ним меньше всего проблем.
Задача как раз начинать не с ядра.
Как же не с ядра, если сначала делается обвязка вокруг стандартного функционала?
Во первых, ещё ничего не делается. А во вторых, само ядро не трогается.
Ну понятно, что не сам Modx. Взаимодействие со стандартным функционалом через RestAPI. Как тут можно по-другому понять?
«Ядро без дополнений… понятно, что не ядро...»
Как хочешь, так и понимай. Сколько лет MODX, а базового решения для апи нет. Сделать универсальное решение — большое дело. Хотя бы через компонент.
Как хочешь, так и понимай. Сколько лет MODX, а базового решения для апи нет. Сделать универсальное решение — большое дело. Хотя бы через компонент.
Свежий коммент Марка с канала MAB:
Mark Hamstra
I think we first need a rest API and then to think about a new frontend. And there's also a mab decision about that from last year.
When there's an API, the frontend framework can be more easily changed in the future. Or there could be different ones even.
Mark Hamstra
I think we first need a rest API and then to think about a new frontend. And there's also a mab decision about that from last year.
When there's an API, the frontend framework can be more easily changed in the future. Or there could be different ones even.
Ребят, ему это вообще интересно? Сам Modx? Начнем с этого.
Марку да. Джейсон под вопросом, что очень печалит.
Командира можно поменять? Василий бы справился.
Он уже согласился? Что то я не помню, что ему это интересно.
Зануда. Так и ломается инициатива. А вдруг я охрелиард денег добавлю? Я например верю в чудеса. С детства.
Мне кажется я сейчас в сообществе самый активный =). Западных думаю уже замучил своей активностью.
Сделай паузу. Если желание не пропадет, значит твоё дело.
Не шутка. Пауза очень важно. Есть золотое правило не отвечать на комментарий раньше 10 минут. Редко получается. Первые шаги, эмоции.
Сижу в последнее время и думаю куда слезать с MODX и что на нём ещё держит.
Нравится дерево ресурсов, нравится PDOTools, но главное, можно сравнительно быстро сделать магазин с интеграцией с 1С.
Не нравится что все шаблоны чанки в БД. Не нравятся эти дебильные поля типа LongTitle который ни разу не были нужны. Не нравятся ТВ-костыли. Да и добавление свойств товарам в Минишопе — тоже пойди пойми как лучше сделать. Не нравится сложность создания собственных модулей. Ну то есть вот этих CMP или как оно.
Я хочу быстро накидать схему для БД под мои нужды, как это делается в какой-нибудь Strapi или Directus. И вывести всё это на фронт привычными средствами без всяких там реактов или вью. Потому что у них свои недостатки и, как уже говорилось, они не вечны. Но при этом, чтоб можно было и ими пользоваться если захочется. Поэтому мне нравится концепция Философа с его ПризмойЦМС, но там нод.джиэс и вот это вот всё.
Может MODx или новая MODx-Like CMS предоставить это в обозримом будущем? Есть смысл сохранять обратную совместимость для поддержки старых модулей или большая часть сообщества сидит здесь из-за минишопа и PDOTools, которые с новым API могут стать лучше? Не станет ли поддержка обратной совместимости тормозом? Сколькими дополнениями вы реально пользуетесь? У меня, помимо ПДОтулс и Минишопа это MSearch2, Office, CodeMirror ну + платёжные системы и 1С. Полезные мелочи типа Units можно не рассматривать — их можно самому за вечер переписать.
Нравится дерево ресурсов, нравится PDOTools, но главное, можно сравнительно быстро сделать магазин с интеграцией с 1С.
Не нравится что все шаблоны чанки в БД. Не нравятся эти дебильные поля типа LongTitle который ни разу не были нужны. Не нравятся ТВ-костыли. Да и добавление свойств товарам в Минишопе — тоже пойди пойми как лучше сделать. Не нравится сложность создания собственных модулей. Ну то есть вот этих CMP или как оно.
Я хочу быстро накидать схему для БД под мои нужды, как это делается в какой-нибудь Strapi или Directus. И вывести всё это на фронт привычными средствами без всяких там реактов или вью. Потому что у них свои недостатки и, как уже говорилось, они не вечны. Но при этом, чтоб можно было и ими пользоваться если захочется. Поэтому мне нравится концепция Философа с его ПризмойЦМС, но там нод.джиэс и вот это вот всё.
Может MODx или новая MODx-Like CMS предоставить это в обозримом будущем? Есть смысл сохранять обратную совместимость для поддержки старых модулей или большая часть сообщества сидит здесь из-за минишопа и PDOTools, которые с новым API могут стать лучше? Не станет ли поддержка обратной совместимости тормозом? Сколькими дополнениями вы реально пользуетесь? У меня, помимо ПДОтулс и Минишопа это MSearch2, Office, CodeMirror ну + платёжные системы и 1С. Полезные мелочи типа Units можно не рассматривать — их можно самому за вечер переписать.
Ах да! Бесит что нельзя легко и просто сделать свою сборку MODx со своим набором модулей. Ипа вот сборка под блог, а вот под магаз. Знаю, что это можно, но это нифига не просто.
Очень сомневаюсь что кто-то из нашего сообщества сможет написать каркас (а он нужен хоть какой-то, иначе будет хаос) лучше Vue/React/Angular/etc. Давайте все пилить с нуля еще 10 лет. Кстати, Николай Ланец, также неоднократно писал что использует много готовых решений.
Я, простите, не особо программист и, возможно, не совсем правильно понимаю, что вы имеете в виду под каркасом, но слова вью и рекат мне не нравятся из-за сео. Да это решаемо, но я плохо понимаю как сделать сайт с миллионом страниц с SSR. Может и можно. Но это вот хранение одного и того же по сути на винте и в БД. Ну как-то… хз.
А по поводу пилить 10 лет… Ну давайте 10 лет пинать труп. Вон рядом ребята джумлу с вордпрессом пинают, а мы чем хуже? Мне кажется концепции ЦМС с жёстко прописанными полями в одной табличке и допполями в другой несколько устарели. И никакая быстрая админка эти косяки не исправит. Смысл тогда?
… или я всё не так понял и пойду-ка я спать.
А по поводу пилить 10 лет… Ну давайте 10 лет пинать труп. Вон рядом ребята джумлу с вордпрессом пинают, а мы чем хуже? Мне кажется концепции ЦМС с жёстко прописанными полями в одной табличке и допполями в другой несколько устарели. И никакая быстрая админка эти косяки не исправит. Смысл тогда?
… или я всё не так понял и пойду-ка я спать.
Я имел ввиду Vue/React/Angular в админке, вроде тут про нее, родимую, топик. А на чем уже фронт ваять это выбор конечного разраба.
А, ну тут согласен. Что угодно, но не ExtJS. А я про то, что на фронт надо бы что-то кроме Vue/React. Все эти headless CMS какие-то… Странные.
Лучше — точно нет, но тут вопрос не «как», а «что» — современные требования к веб-разработке сильно изменились за последние 3-5 лет и оставаться на уровне «личного сайта моего кота» — значит, быть неконкурентноспособным. Но с другой стороны, делая универсальное решение, можно «скатиться» в такой слой абстракций, что увеличит порог вхождения (взгляните на EmberJS — то, что в ближайшие годы будет добавлено в Реакт или Вью, «всё уже было в Симпсонах»). Но это уже меньшее из зол: обучаемость — хороший фильтр, что в своё время спасло MODX от превращения в Джумлу или ВордПресс. Нужны реальные кейсы, реальные проекты, чтобы понимать, к чему мы хотим двигаться, что видеть нового, сто оставить неизменным.
Не нравятся эти дебильные поля типа LongTitle который ни разу не были нужны.Хм, у меня pagetitle — title, а longtitle — h1, а Вы как делаете?
А мне достаточно pagetitle. Более того мне иногда и Content не нужен, я уж не говорю про introtext и description.
Если данные поля именно ты не используешь, это не значит, что их нужно выпелить за ненадобность, мне недавно написал один человек который каждую страницу на сайте хранит в отдельном шаблоне))) понятное дело, что так тоже както «работает», но это не есть верная и правильная практика ?
Я сам должен определять набор полей. Надо longtitle и introtext для какого-то типа даннх — сделал. Не нужно это — не делаешь. Из коробки должен быть только минимальный набор. Наличие дополнительных полей когда-то было для меня главной фишкой MODx, но сейчас их реализация не радует.
и что мешает вывод данных полей отключить и не видеть их, если они так тебе мешают?
То, что они всё-равно подгружаются, а потом скрываются. Они всё-равно есть. Это всё-равно костыль. Но суть не в этом. Суть в том, что практически всё хранится в modx_site_content + куски распиханные по таблицам ТВ. А я хочу разделять разные типы данных. Есть у меня список магазинов, которому не нужны ни longtitle, ни introtext, но нужны координаты — сделал отдельную таблицу в базе с нужными полями. Когда база в удобоваримом виде, многое становится проще и работает быстрее.
Создание новых сущностей-таблиц без лишних полей. Для решения этой задачи в MODX есть даже на выбор инструменты: MIGX и modExtra
И CMPGeneratorPro. Вот он более-менее близок к тому, что нужно. Но это платное дополнение, а должно бы быть стандартным инструментом из коробки в идеале.
CMPGenerator
Да-да. Есть инструменты. Кто б спорил? Но всё познаётся в сравнении.
Хм, у меня pagetitle — title, а longtitle — h1, а Вы как делаете?Скажите, а как при таком подходе заполняют контент-менеджеры?
Два раза пишут одно и тоже в поле pagetitle / longtitile, ведь далеко не все страницы имеют тайтл отличный от h1? Ну и плюс MODX генерирует url по полю pagetitile, а в нем находиться title, который по определению обычно более длинный чем h1 и будут получаться очень длинные URL.
Я делаю так h1 — это pagetitle, а в head проверка — если longtitle пуст то берем в title значение тоже что и для h1, если заполнен — то ставим в тайтл значение из longtitle.
Два раза пишут одно и тоже в поле pagetitle / longtitileЗачем? можно написать чтото типо такого:
{$_modx->resource.longtitle ?: $_modx->resource.pagetitle~' | '~$_modx->config.site_name}
title нужен в первую очередь для SEO и он может отличаться от заголовка страницы
Так и есть. просто мне кажется логичным задавать h1 в pagetitle
А если нужно задать отличный от него title то прописывать его в longtitle
Но это дело вкуса.
А если нужно задать отличный от него title то прописывать его в longtitle
Но это дело вкуса.
Если судить по названиям, «pagetitle» — заголовок страницы, «longtitle» — длинный заголовок. То есть логично, что pagetitle для title, а longtitle для h1. Но это конечно же вкусовщина всё. Я раньше вообще делал отдельные tv для title и description :)
Да у всех свой подход, кому-то так удобно, кому-то эдак. Если совпадают title и h1, что на моей практике редко встречалось, то просто продублируют, ничего сложного нет.
Вот все, что вы написали здесь и ниже по тредику… посмотрите на October CMS + Builder.
«Из коробки» Октябрь полное противопоставление MODX с т.з. перегруженнсоти функциональностью последнего, он очень аскетичен, ничего лишнего. Все, что нужно ставится плагинами, даже система пользователей («из коробки» только один админ). И e-commerce там такой же модульный на базе Shopaholic.
«Из коробки» Октябрь полное противопоставление MODX с т.з. перегруженнсоти функциональностью последнего, он очень аскетичен, ничего лишнего. Все, что нужно ставится плагинами, даже система пользователей («из коробки» только один админ). И e-commerce там такой же модульный на базе Shopaholic.
Да вот как раз смотрю. Думаю, может пойти дальше и изучать сразу Laravel?
Это два разных инструмента. Октябрь это Лара с дополнительнымм API и некоторыми отличиями и готовой админкой. Чистая Лара, это совсем другая категория проектов. Лару стоит начинать использовать там, где Октябрь перестает справляться.
Минусуя @Pavel Lautsevich вы расписываетесь в собственной никчемности — Павел не критикует и не осуждает MODX, он субъективно советует, что «подсмотреть» у других, чтобы сделать лучше. Если бы MODX «был лутши всех!!!», мы бы тут не собрались. Проще учиться на чужих ошибках и успехах.
Я минуснул за то, что его сообщение вообще не в тему топика (на мой взгляд). Плюс
каждое второе сообщение на modx.pro от Павла, это сообщение в сторону октября. Ну серьезно, это даже не смешно. Давайте теперь каждый из нас будет постоянно говорить о наиболее импонируемых CMS. Почему нет?!
P.S. Называя людей никчемными за минус в интернете, вы подписываетесь в собственной никчемности. На это предлагаю закончить, так как топик совсем о другом.
каждое второе сообщение на modx.pro от Павла, это сообщение в сторону октября. Ну серьезно, это даже не смешно. Давайте теперь каждый из нас будет постоянно говорить о наиболее импонируемых CMS. Почему нет?!
P.S. Называя людей никчемными за минус в интернете, вы подписываетесь в собственной никчемности. На это предлагаю закончить, так как топик совсем о другом.
Минусуя того товарища выше, я лично минусанул коммент того товарища выше, и только его, но никак не поставил минус самой цмс. Просто он реально достал своим агрессивным маркетингом и спамит октябрь где только может и не может.
Прочитав все комментарии, скажу свое мнение.
По моему опыту скажу, что было бы отличным решением разработать, что сейчас делает Дмитрий Лукьяненко: Evo с Laravel.
По поводу плагинов.
Я уже года 2 не скачиваю никакие плагины и сниппеты, кроме pdoTools, FormIt, Search, TinyMCE, MIGX, Collections.
Всё остальное я пишу сам.
Поэтому лично мне пофиг на совместимость (что её не будет) в новых версиях.
Для меня в идеале:
Смысл в том, чтобы можно было бы делать сайты «как раньше», но и есть возможность собрать самолёт. И всё из коробки (подтянуть любую библиотеку через composer).
По моему опыту скажу, что было бы отличным решением разработать, что сейчас делает Дмитрий Лукьяненко: Evo с Laravel.
По поводу плагинов.
Я уже года 2 не скачиваю никакие плагины и сниппеты, кроме pdoTools, FormIt, Search, TinyMCE, MIGX, Collections.
Всё остальное я пишу сам.
Поэтому лично мне пофиг на совместимость (что её не будет) в новых версиях.
Для меня в идеале:
- Мне нужна админка, как сейчас EVO/REVO (смысл, твшки, чанки).
- Чтобы по-умолчанию на файлах (чтобы парсило папку с шаблонами и чанками, по примеру Grav CMS). Но можно было бы в настройках включить «Хранить чанки и сниппеты в базе».
- Под капотом Laraver (что угодно, лишь бы современное, масштабируемое), с которым что угодно можно сделать.
Смысл в том, чтобы можно было бы делать сайты «как раньше», но и есть возможность собрать самолёт. И всё из коробки (подтянуть любую библиотеку через composer).
Подписываюсь под каждый словом.
По моему опыту скажу, что было бы отличным решением разработать, что сейчас делает Дмитрий Лукьяненко: Evo с Laravel.Таких как Дмитрий в лагере Revolution не нашлось. Именно поэтому и был предложен более простой вариант. Но я не уверен, что даже этот вариант сообщество потянет. Это раз.
А в третьих, что там напилит Дмитрий покажет время. И если напилит. И то что получиться, думаю, будет интересно ему и ещё троим-четверым (не в обиду Дмитрию). И пока Revo не скатилась до уровня Evo нужно принимать срочные меры. Иначе через несколько лет его постигнет судьба младшего брата.
Подумал пару дней. Вижу, что Василию нравится.
Ребят. Не взлетит. Да и самим понятно. Я скептик, но не отговариваю.
Не так это делается.
Ребят. Не взлетит. Да и самим понятно. Я скептик, но не отговариваю.
Не так это делается.
Говорим, что обратная совместимость не нужна. И в те же грабли. API ничего не даст.
Пробуйте, если заняться нечем. Подумайте лучше еще раз.
Пробуйте, если заняться нечем. Подумайте лучше еще раз.
А зачем она нужна? Лично я не собираюсь ничего обновлять.
Мне нужна удобная CMS для одностраничников (пятистраничников) и сложных проектов (веб-аппликаций) в одном движке.
С админкой, как в EVO/REVO.
Вот тебе, например, для чего нужна обратная совместимость?
Мне нужна удобная CMS для одностраничников (пятистраничников) и сложных проектов (веб-аппликаций) в одном движке.
С админкой, как в EVO/REVO.
Вот тебе, например, для чего нужна обратная совместимость?
Я противник обратной совместимости.
October CMS.
После публикации этого поста Марк обратил внимание на мой PR (@Иван Бочкарев приложил руку) с возможностью расширения класса modX, дающий разработчикам больше контроля над ядром, ибо можно создать свой класс приложения и не ждать милости от core-разработчиков. Марк высоко оценил данную возможность.
Но вот пришел главный и поставил жирную точку. Цитата:
Ну что я могу сказать. Этот человек делает всё, чтобы MODX остался там, где он есть.
Но вот пришел главный и поставил жирную точку. Цитата:
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 остался там, где он есть.
и поставил жирную точку… а без этого PR идея описанная в топике нежизнеспособна?
Этот PR завязан на того же Джейсона. Требуется его благоволение, чтобы добавил. Да ещё и вопрос куда. В третью версию — значит выбросить в пропасть. А во вторую вряд ли добавил бы.
А идея с админкой — это альтернатива, которая полностью исключает необходимость обращения к этому товарищу. Это просто обычный компонент, но не совсем обычный. ))
Современные тенденции требуют использования модных JS фреймворков. И тут я полностью выключаюсь из процесса ибо я не дизайнер, не верстальщик и у меня нет большого опыта работы с Vue/React/Angular и т.п. фреймворками. Могу чисто языком поработать ))
А идея с админкой — это альтернатива, которая полностью исключает необходимость обращения к этому товарищу. Это просто обычный компонент, но не совсем обычный. ))
Современные тенденции требуют использования модных JS фреймворков. И тут я полностью выключаюсь из процесса ибо я не дизайнер, не верстальщик и у меня нет большого опыта работы с Vue/React/Angular и т.п. фреймворками. Могу чисто языком поработать ))
спасибо, а то
поставил жирную точкупугает
А идея с админкой — это альтернатива, которая полностью исключает необходимость обращения к этому товарищу.— да будет так! Очень интересно.
Ну я писал про свой PR. И именно в нём Джейсон и высказался наконец-то. Ибо в Слаке он тогда ответил «нафиг», а на просьбу объяснить просто забил.
Современные тенденции требуют использования модных JS фреймворков. И тут я полностью выключаюсь из процесса ибо я не дизайнер, не верстальщик и у меня нет большого опыта работы с Vue/React/Angular и т.п. фреймворками.Тебе и не надо работать с фронтендом, в первую очередь нужно написать API — а это бэкенд на PHP.
Любители фронтенда сами подтянутся, когда им будет куда отправлять запросы для получения данных.
То чувство, когда этот Джейсон напоминает одного человека в России про которого нельзя говорить(Пу)
А по теме: каждый день захожу читаю, интересно, но от себя пока нечего добавлять… только слово НАДО что-то делать и развивать, а то как тут уже много раз писали застрянем в аналоговом веке и все тут…
А по теме: каждый день захожу читаю, интересно, но от себя пока нечего добавлять… только слово НАДО что-то делать и развивать, а то как тут уже много раз писали застрянем в аналоговом веке и все тут…
То чувство, когда этот Джейсон напоминает одного человека в России про которого нельзя говорить(Пу)Оно и видно, как никто (ты) не говорит.
А по теме: каждый день захожу читаю, интересно, но от себя пока нечего добавлять…Только политоты накинуть на вентилятор, молодец.
я агент навального)) создаю резонанс)
но справедливости ради: в целом так говорят.
но справедливости ради: в целом так говорят.
Константин, не шали. Прокляну! ))
По поводу последнй цитаты… Представляете уровень его самомнения? Он не фанат статических методов. Не нравиться, не используй. А кому то нравится. И что? Пшли на… Просто удивительно!
У нас и веселее высказывания были:
Собственно, с тех пор я как-то и перестал спорить. Тут люди десятилетиями работают, им виднее.
And I'm very surprised by the unnecessary sarcasm. You may have put a lot of work into this, but I've put over a decade of my life into this if you want to play that game. You didn't communicate once on decisions or ask a single question after our initial discussion. Open Source is about collaboration.github.com/modxcms/revolution/pull/13900#issuecomment-390403195
And further, a little respect for the people and company that made this software possible in the first place might be in order here.
Собственно, с тех пор я как-то и перестал спорить. Тут люди десятилетиями работают, им виднее.
Сколько не смотрю на эти переписки и обсуждения, не могу понять, к чему терпеть и ждать не пойми чего столько времени, когда итак понятно что из этого выйдет. То есть ничего. Разве что иностранцы ввиду своей галантности ещё не послали российских коллег. Так что это садо-мазо может длиться вечно))
Не надо ничего ждать, надо брать и делать.
Но пока никто не взял и не сделал — остаётся только ждать, увы.
Но пока никто не взял и не сделал — остаётся только ждать, увы.
Согласен с Васей.
Кто может уже помогает, а не размышляет.
Кто может уже помогает, а не размышляет.
Какие есть предложения по API? RestAPI, JSON-API или GraphQL?
Позвольте спросить, а чем вам не угодил подход, который начинал пропагандировать лет 7 назад @Fi1osof?
Я сейчас о программировании на процессорах. Нужна новая админка — бери, да пиши.
MODX Evo/Revo Сейчас привлекает многих тем, что можно использовать чужие наработки без проблем. А с новой админкой что? Опять проходить все круги ада — Tickets, miniShop и бла-бла-бла… Думаю это никому не нужно будет. Но, как бы не хотелось чего-то новенького да удобненького, большинство все равно будет пользоваться стареньким и привычненьким.
Опыт Evo тому пример. Я лично выступал инициатором реноваций, но всегда это заканчивалось неудачей. И так продолжалось до тех пор, пока я не написал 100% совместимый шлюз от DBAPI в Eloquent. Дальше стало проще — бек можно развивать вместе с админкой, но энтузиазма лично у меня уже не осталось.
Я сейчас о программировании на процессорах. Нужна новая админка — бери, да пиши.
MODX Evo/Revo Сейчас привлекает многих тем, что можно использовать чужие наработки без проблем. А с новой админкой что? Опять проходить все круги ада — Tickets, miniShop и бла-бла-бла… Думаю это никому не нужно будет. Но, как бы не хотелось чего-то новенького да удобненького, большинство все равно будет пользоваться стареньким и привычненьким.
Опыт Evo тому пример. Я лично выступал инициатором реноваций, но всегда это заканчивалось неудачей. И так продолжалось до тех пор, пока я не написал 100% совместимый шлюз от DBAPI в Eloquent. Дальше стало проще — бек можно развивать вместе с админкой, но энтузиазма лично у меня уже не осталось.
Я бы склонялся к JSON-API (т. к. это надмножество REST) и GraphQL, потому что есть кейсы, когда его выбор оправдан. Для PHP есть готовые решения: thecodingmachine.io/graphqlite-graphql-in-php-easy, например, выглядят очень воодушевляюще. Спрос к GraphQL будет неизменно расти (маркетинг — такой маркетинг), так что решив эту задачу, мы закроем большой пласт потребностей охипстеревших фронтендеров (да кого я обманываю — я сам такой…).
Я в своих проектах для решения подобной задачи просто использую DSL (Loopback 4), который нивелирует разницу между выбираемой технологией под абстаркцию описания типов (по аналогии, как это делается в MODX, когда описывается схема таблицы в XML). В этом случае мы сможем решить ещё и проблему поддержки нескольких типов БД — MySQL, PostgreSQL, NoSQL.
Я в своих проектах для решения подобной задачи просто использую DSL (Loopback 4), который нивелирует разницу между выбираемой технологией под абстаркцию описания типов (по аналогии, как это делается в MODX, когда описывается схема таблицы в XML). В этом случае мы сможем решить ещё и проблему поддержки нескольких типов БД — MySQL, PostgreSQL, NoSQL.
По сравнению с другими у GraphQL сложнее порог входа. Нужно учить язык. JSON-API в этом плане проще. И масштабируемее. Можно начать с простого REST, а закончить сложными запросами. Есть ещё OpenAPI. В общем только выбирай.
Субъективно. Мне тоже привычнее старый-добрый REST, но на четвёртую ночь «красноглазия» с зависимыми выборками понимаешь, что «лучше день потерять, потом за пять минут долететь». Оба решения имеют большое количество недостатков (докладов на эту тему за последние два года — на три сезона), так что тут нельзя оперировать понятием «лучше». если сделаем оба, утрём нос тем, кто «ниасилил».
Плюсую за GraphQL.
Сегодня общался с евангелистом GraphQL, говорит, GraphQL «мёртв»…
Интересно, Цукерберг уже в курсе? )
Лично я для старта выбрал Swagger, т.е. OpenAPI спецификацию. Она более читабельна, чем JSON-API.
Лично я для старта выбрал Swagger, т.е. OpenAPI спецификацию. Она более читабельна, чем JSON-API.
Пару дней мониторю эту тему! Вродь как все просто! На событии OnPageNotFound ловим урлы типа /api/v1/* подключаем класс компонента! Для реализации класса можно условиться, что вместо * идут основные параметры запроса разделенные слешами:
1) Тип ресурса
2) Метод
3) Критерий
Таким образом мы получим запросы типа:
Ну а понимание того, что мы хотим сделать с ресурсом, нам даст метод запроса (GET, POST, UPDATE ...).
Сам класс компонента должен проверить права (тут есть вопросы!), корректно определить пожелания пользователя из запроса, произвести валидацию данных, дернуть соответствующий процессор и вернуть ответ!
Если админка только для разработчика, то для обращения по апи пользователь должен быть авторизован в текущем контексте и иметь соответствующие права.
Вродь как этого достаточно для старта, или я опять не вижу кучу подводных камней?
1) Тип ресурса
2) Метод
3) Критерий
Таким образом мы получим запросы типа:
/api/v1/resources/getlist/ = /api/v1/resources/ - получаем список сущностей - массив объектов
/api/resources/get/{$id}/ - получаем сущность - объект
Конечно же сервер должен вернуть нам JSON.Ну а понимание того, что мы хотим сделать с ресурсом, нам даст метод запроса (GET, POST, UPDATE ...).
Сам класс компонента должен проверить права (тут есть вопросы!), корректно определить пожелания пользователя из запроса, произвести валидацию данных, дернуть соответствующий процессор и вернуть ответ!
Если админка только для разработчика, то для обращения по апи пользователь должен быть авторизован в текущем контексте и иметь соответствующие права.
Вродь как этого достаточно для старта, или я опять не вижу кучу подводных камней?
Вот помониторь лучше документацию по MODX Rest
Событие onPageNotFound тут не при чем.
Событие onPageNotFound тут не при чем.
Спасибо! Это упрощает задачу! Если я все правильно понял, то остается написать контроллер, который будет дергать соответствующие классы и их методы?
Именно так. Я тебе больше скажу. Переодически в комментариях ребята дают ссылки на свои уже сформированные библиотеки контроллеров. Из последнего вот недавно выкладывали
Я бы всё-таки не стал рассматривать REST в реализации MODX. Мало того, что сам стандарт уже старый и ограниченный, так ещё и в MODX он хрен знает как поддерживается. Многие серверы по умолчанию отключают опасные методы. Как в этом случае реализовывать глаголы? Костылями как в Laravel? Есть смысл обратить внимание на JSON-API или OpenAPI, в которых решены многие проблемы REST.
Насколько я знаю он еще и никаких методов кроме GET и POST не поддерживает. Все остальные эмулируются, переводясь в POST. По крайней мере так было, когда я последний раз с этим компонентом фреймворка работал. Все на POST c экшенами выстраивалось.
С другой стороны — может это и к лучшему? Глаголы изначально не рассматриваются, работаем с базовой частью.
С другой стороны — может это и к лучшему? Глаголы изначально не рассматриваются, работаем с базовой частью.
Костылями как в Laravel?Можно по подробнее?
Для интереса можно посмотреть как подобное проходило с WP. В начале один энтузиаст собрал компонент реализующий JSON-API для WP, за несколько лет это решение получило популярность и было впилино в ядро. Если вообще никто не хочет предпринимать, то я мог бы попробовать начать, но боюсь, что у меня нет достаточной компетенции и знаний. Так что Сергей, либо это сделаете вы! Либо я! Но предупреждаю, я это буду делать долго и плохо!
P.S. Да это угроза-).
P.S. Да это угроза-).
Здравствуйте.
Я новичок в Modx(буквально пару недель назад начал активно им пользоваться) так что не кидайтесь пожалуйста тапками.
Вероятнее всего никого не удивлю, но не столько мне как большинству моих друзей(по большей части дизайнеров\фронтенд разрабов) в Modx не хватает GUI редактора(может даже с функционалом по типу — создал блок (самый простой как в блогах — с заголовком картинкой и текстом) и выделив несколько тэгов вставил как чанк — для того что бы программист понимал что к чему когда садится редактировать код в лучшую сторону) по этому они остаются на WP, на котором лично мне ужас как не нравится работать.
В случае если будет GUI редактор дизайнеры, к примеру, могли бы делать наброски, структурировать их в чанки, давая им имена и тем самым облегчая задачу «понимания» кода программисту. Думаю это привлекло бы внимание начинающей аудитории, так как учитывая чистый html css на выхлопе, возможность кастомизировать множество вещей и относительную простоту граф редактора выходит очень(имхо) привлекательная cms как для программиста так и для дизайнера
Надеюсь мое мнение было кому-то полезным
Я новичок в Modx(буквально пару недель назад начал активно им пользоваться) так что не кидайтесь пожалуйста тапками.
Вероятнее всего никого не удивлю, но не столько мне как большинству моих друзей(по большей части дизайнеров\фронтенд разрабов) в Modx не хватает GUI редактора(может даже с функционалом по типу — создал блок (самый простой как в блогах — с заголовком картинкой и текстом) и выделив несколько тэгов вставил как чанк — для того что бы программист понимал что к чему когда садится редактировать код в лучшую сторону) по этому они остаются на WP, на котором лично мне ужас как не нравится работать.
В случае если будет GUI редактор дизайнеры, к примеру, могли бы делать наброски, структурировать их в чанки, давая им имена и тем самым облегчая задачу «понимания» кода программисту. Думаю это привлекло бы внимание начинающей аудитории, так как учитывая чистый html css на выхлопе, возможность кастомизировать множество вещей и относительную простоту граф редактора выходит очень(имхо) привлекательная cms как для программиста так и для дизайнера
Надеюсь мое мнение было кому-то полезным
P.S. Да, я знаю, что есть фигма и прочие удобные сервисы для дизайнеров, но на большинстве из них либо A) Размеры не те(назвал блок — h1 а в css выхлопе font-size: 18px, когда дизайнер подбирая на глаз видел около 25-30) Б) Отступ 348.789 пикселей слева и 348.211 справа В) Если много мелких иконок то их скачивание(кстати выбор между x1\x2 и т.п. так же несколько раз доставлял хлопоты) занимает много времени, а если дизайнер сразу заливает все в папку(к примеру /assets/templates/img/) то мороки снимается немало
Поддержу в этом вопросе Марка — по поводу GUI редактора.
Несколько месяцев назад у нас сменились СЕО специалисты и те что пришли — скорее всего ранее работали только с WordPress. На wordpress есть куча визуальных редакторов для страниц (WPPageBaker, Elementor) которые позволяют основываясь на bootstrap разметке создавать в админке контейнеры, дробить их на колонки и выводить разноплановую информацию. И теперь для меня на modx настал маленький ад. Потому что специалисты просят выводить информацию на странице в совершенно случайном порядке — у этой новости пишем два предложения, потом набор из 5 иконок с текстом, потом еще абзац текста, потом слайдер с изображениями, потом адаптивную таблицу с ценами, потом два абзаца текста и что-то еще. А следующей новости — все совершенно по другому… Стоит привести верстку страницы к желаемому виду, завести новые поля у шаблона страницы новости, показать всем как и что заполнять, как на следующий день принимается решение что все нужно по другому либо же что вот эта свежая новость должна выглядеть совершенно иначе, а старые — пусть выглядят как и были. И так по 30 проектам. И было бы действительно не плохо иметь возможность установить дополнительно визуальный редактор, и пусть бы они сами это лепят.
Несколько месяцев назад у нас сменились СЕО специалисты и те что пришли — скорее всего ранее работали только с WordPress. На wordpress есть куча визуальных редакторов для страниц (WPPageBaker, Elementor) которые позволяют основываясь на bootstrap разметке создавать в админке контейнеры, дробить их на колонки и выводить разноплановую информацию. И теперь для меня на modx настал маленький ад. Потому что специалисты просят выводить информацию на странице в совершенно случайном порядке — у этой новости пишем два предложения, потом набор из 5 иконок с текстом, потом еще абзац текста, потом слайдер с изображениями, потом адаптивную таблицу с ценами, потом два абзаца текста и что-то еще. А следующей новости — все совершенно по другому… Стоит привести верстку страницы к желаемому виду, завести новые поля у шаблона страницы новости, показать всем как и что заполнять, как на следующий день принимается решение что все нужно по другому либо же что вот эта свежая новость должна выглядеть совершенно иначе, а старые — пусть выглядят как и были. И так по 30 проектам. И было бы действительно не плохо иметь возможность установить дополнительно визуальный редактор, и пусть бы они сами это лепят.
спасибо. Слышал о нем много плохого, но пока сам не попробуешь не узнаешь. Нужно будет ознакомиться.
modmore.com/contentblocks/ — более, чем на 100% делает все что вы пишете и ни какого ада, ну, чуть денег, да
Ага, спасибо. Об этом компоненте не слышал.
Ого, я как ни искал не мог найти, а они оказываются есть.
Извиняюсь за преждевременный коммент и спасибо за совет =)
Извиняюсь за преждевременный коммент и спасибо за совет =)
Я вот работаю только с MODX. Пробовал и WP и Joomla. Не завелось. А вот с MODX взял и начал что-то писать. Все просто и интуитивно понятно для меня. Только два дня потратил на освоение ModExtra. MODX Revo почти идеален ;-). Может он и устаревает, но от новой MODX-like системы хотелось бы такой же легкости освоения, стандартизованную админку и стандартные средства такие как сниппеты, чанки, шаблоны, tv, formit, fenom,pdoTools, minishop, tickets, множество готовых компонентов для программирования-сборки сайтов, исчерпывающею русскую документацию и активное сообщество. И это главное :). Например WP мне не понравился зоопарком плагинов. Для того чтобы что-то сделать нужно изучить плагины, на которых сделали сайт до меня. И таких плагинов очень много. Как-то пробовал сделать програмку на VB сдох на программировании авторизации пользователей. А в MODX все что нужно для авторизации уже есть. Пробовал освоить Октябрь, но выяснилось, что он заточен под англоязычных, и документация приложений в магазине не слишком подробная.
У MODX есть недостатки: сайт тупит когда много ресурсов и tv, нет дополнений таких как чат, форум, делать компоненты на продажу не слишком выгодно (для большей части аудитории хватает бесплатных и на платные мало покупателей, не считая конечно office и msearch). С tv, наверно, можно было сделать галочку «хранить в отдельной таблице» и, при ее включении, создавать для tv таблицу с типом value определенном правилами tv и переносить в нее все данные этой tv.
Уф. Высказался. Не очень мне нравится разговоры про новый MODX и отказ от обратной совместимости.
У MODX есть недостатки: сайт тупит когда много ресурсов и tv, нет дополнений таких как чат, форум, делать компоненты на продажу не слишком выгодно (для большей части аудитории хватает бесплатных и на платные мало покупателей, не считая конечно office и msearch). С tv, наверно, можно было сделать галочку «хранить в отдельной таблице» и, при ее включении, создавать для tv таблицу с типом value определенном правилами tv и переносить в нее все данные этой tv.
Уф. Высказался. Не очень мне нравится разговоры про новый MODX и отказ от обратной совместимости.
Только что заметил, плюсик с меня
Просто оставлю это здесь))) На секундочку, это был 2015 год… Эх, сколько было надежд
www.slimframework.com/2015/02/23/modx-cms-and-slim.html
www.slimframework.com/2015/02/23/modx-cms-and-slim.html
Заметка о ходе разработки API. Также добавил в статью ссылку на демку.
П.С. Какие-то странности с уровнем комментариев. Писал в корень — показывает 3 точки, хотя ссылки на parent нет.
Я прочитал заметку, но не понял в чем суть… Получается мы берем MODX и к нему прикручиваем Slim 4 + доп. решения. Зачем? А чтобы получить API MODX (которое, в принципе уже и так есть) и прикрутить к нему собственную админку на чем хочешь… это выглядит как-будто из Оки сделать Лэнд Крузер
которое, в принципе уже и так естьAPI в студию!
Есть-то оно есть, а вы пробовали что-то более-менее серьёзное на нём организовать? Мне, например, удобнее на ЛендКрузере ездить, не вижу смысла пересаживаться на Оку.
Во-первых, это не готовое API, а инструкция по его созданию.
Во-вторых, про это уже говорили. Данное решение изучалось. Оно оказалось крайне ограниченное. Ничего кроме items/15 вы не получите.Т.е. статью с комментариями одним запросом никак не получить. И поля никак не указать. Так что на этом серьезное API не сделаешь.
В-третьих, сам Джейсон недавно в обсуждениях на Github писал, что делает API через Slim. Т.е. даже сам сапожник не носит свои сапоги.
В-четвертых, задача попробовать минимизировать зависимость от core-разработчиков.
И в-пятых, третья версия MODX планировалась на Slim 3. Возможно наше решение даст толчок для реализации этих планов.
Так что всё пока логично. А вас, товарищ, мы из групповухи вычеркиваем.)
Во-вторых, про это уже говорили. Данное решение изучалось. Оно оказалось крайне ограниченное. Ничего кроме items/15 вы не получите.Т.е. статью с комментариями одним запросом никак не получить. И поля никак не указать. Так что на этом серьезное API не сделаешь.
В-третьих, сам Джейсон недавно в обсуждениях на Github писал, что делает API через Slim. Т.е. даже сам сапожник не носит свои сапоги.
В-четвертых, задача попробовать минимизировать зависимость от core-разработчиков.
И в-пятых, третья версия MODX планировалась на Slim 3. Возможно наше решение даст толчок для реализации этих планов.
Так что всё пока логично. А вас, товарищ, мы из групповухи вычеркиваем.)
В-последних, я в вашу групповушку не претендую, я ваш вариант решения понять хочу. Хотя бы может ссылку на гитхаб разместили
Во-первых и вторых — это не готовое API, и не и инструкция по его созданию, а базовые классы, которые можно расширять, кому как нужно, и да — это далеко не самое удобное решение.
В-третьих, сам Джейсон, я более чем уверен, имел в виду, что когда ему нужно создать API-based решение использует Slim (а Джейсон, правда сапожник?)
В-четвертых — В-пятых, третья версия планировалась на Slim 3, да, планировалась (в 2015), но не как надстройка над MODX 2, правильно? Я так понимаю в далеком 2015 сапожник Джейсон мечтал о PSR-7 и думал о Slim 3 и XPDO 3. Но тяга к обратной совместимости и прочие факторы дают о себе знать
Во-первых и вторых — это не готовое API, и не и инструкция по его созданию, а базовые классы, которые можно расширять, кому как нужно, и да — это далеко не самое удобное решение.
В-третьих, сам Джейсон, я более чем уверен, имел в виду, что когда ему нужно создать API-based решение использует Slim (а Джейсон, правда сапожник?)
В-четвертых — В-пятых, третья версия планировалась на Slim 3, да, планировалась (в 2015), но не как надстройка над MODX 2, правильно? Я так понимаю в далеком 2015 сапожник Джейсон мечтал о PSR-7 и думал о Slim 3 и XPDO 3. Но тяга к обратной совместимости и прочие факторы дают о себе знать
Авторизуйтесь или зарегистрируйтесь, чтобы оставлять комментарии.