Василий Наумкин

У нас и веселее высказывания были:

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.

And further, a little respect for the people and company that made this software possible in the first place might be in order here.

github.com/modxcms/revolution/pull/13900#issuecomment-390403195

Собственно, с тех пор я как-то и перестал спорить. Тут люди десятилетиями работают, им виднее.

То чувство, когда этот Джейсон напоминает одного человека в России про которого нельзя говорить(Пу)

Оно и видно, как никто (ты) не говорит.

А по теме: каждый день захожу читаю, интересно, но от себя пока нечего добавлять…

Только политоты накинуть на вентилятор, молодец.

Современные тенденции требуют использования модных JS фреймворков. И тут я полностью выключаюсь из процесса ибо я не дизайнер, не верстальщик и у меня нет большого опыта работы с Vue/React/Angular и т.п. фреймворками.

Тебе и не надо работать с фронтендом, в первую очередь нужно написать API — а это бэкенд на PHP.

Любители фронтенда сами подтянутся, когда им будет куда отправлять запросы для получения данных.

Я думаю, эти вопросы решит тот, кто начнёт делать RestApi дополнение.

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

На данный момент, насколько я понимаю, никакая ORM вообще не нужна, потому что мы будем работать с готовыми объектами и процессорами MODX, делая к ним запросы, получая ответ, обрабатывая и отдавая в чистом виде наружу.

RestApi — это просто слой абстракции над ядром MODX со всеми его сущностями.

Объекты MODX работают через xPDO, никуда от него не денешься. Не писать же сразу все свои modResource, modDocument и т.д. с их логикой — это уже точно не поднять.

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

Затем, чтобы не распугать всё сообщество и не переименовывать modx.pro

А если серьёзно — такой подход ничем никого не обязывает и ни к чему не привязывает. Учитывая, как обстоят дела с финансированием и свободным временем у разработчиков — это единственный, на мой взгляд, реальный вариант хоть что-то сделать.

Выкинуть MODX никогда не поздно, но не нужно это делать в самом начале.

На первом этапе это можно пропустить и задействовать рабочие коннекторы.

Не соглашусь, API здесь первично.

Если работать с тем, что есть — у нас опять будут разные костыли, потому что нынешние процессоры завязаны на нынешнюю админку и от этого нужно избавиться. Плюс, автоматическая генерация документации будет возможна только по новому API.

А вот как появится такое API (хотя-бы для работы хоть с чем-то простым), тогда можно начинать и фронтенд. Дальше обновляется API и за ним идёт админка.

В моём представлении — вот так.

Обратная совместимость с костылями — именно то, что завело нас в текущую ситуацию.

На мой взгляд — это единственный реальный вариант.

Нужно 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.

Всё сам делаю: и контроллеры, и процессоры и админка на Nuxt.js в дизайне самого сайта.

По сути, админка — это просто специальный раздел сайта, который требует особых прав. Юзер логинится на сайт и может работать в этом разделе, всё выглядит одинаково.

Проекты серьёзные, так что всё это делается под заказ.

Slim я начал раньше использовать, чем Eloquent.

Честно говоря, сейчас всё идеально работает, даже не знаю, что мне эдакого сможет родной Lumen предложить.

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

Я уже сбился со счёта, в который уже раз ты начинаешь тут строчить по 2 заметки в день, а потом гордо уходишь, хлопнув дверью.

Самому еще эти детские капризы не надоели? Или делись знаниями, и имей в виду, что не всем они могут даваться легко, или молчи уже тогда в тряпочку. А то как девица ветреная себя ведёшь, смотреть противно.

так и не решился попробовать в деле

Если соберёшься — пиши. Всегда помогу, подскажу, у меня там все тропинки уже изведаны.

Поэтому в отдельной локализации смысла нет.

Хотелось дать им возможность самим писать заметки, но оказалось, что это никому не нужно.

Возможно, западные коллеги когда-нибудь тоже придут к мысли, что лучше писать всё в одном месте, нежели растаскивать информацию по мелким личным бложикам. Ну а пока нет — пусть читают нас.

А как насчет связки phpMorphy + Sphinx?

Не совсем понятно, как и зачем их связывать.

Sphinx — это отдельно крутящий демон, которому ты отдаёшь поисковый запрос и он делает всю работу. Включая, например, подсветку найденных слов.

Выглядит это примерно как SQL запрос, только не в БД, а в Sphinx

$query = (new SphinxQL($this->conn))
    ->select('id', 'comment', 'weight() AS weight')
    ->from('topics')
    ->limit($start, $limit)
    ->option('field_weights', [
        'pagetitle' => 100,
        'content' => 50,
        'comment' => 10,
    ])
    ->groupBy('id')
    ->option('max_matches', 1000000)
    ->match(['pagetitle', 'content', 'comment'], $string);

$result = $query->execute();

В mSearch2 же это всё делается вручную, используя формы слов от phpMorphy. Наверное можно просклонять слова в phpMorphy, потом поискать их в Sphinx, потом отдельно отранжировать и соединить ответы — но вряд ли это что-то улучшит, а вот усложнит — наверняка.

Так же интересно узнать про опыт использования phpMorphy2

Я такого не нашёл. Есть только pymorphy2, но он на Python и его ни разу не использовал.

Slim3 + Eloquent, но можно и MODX приспособить — это тоже в планах, попробовать как-то всё совместить.

Я пока только у себя использую, потому что учусь.

Как буду готов — начну писать заметки про это дело, когда сам освою как следует.

А почему для генерации html нужна нода?

Потому что это полностью готовый отрендеренный фронтенд, который не нужно больше обрабатывать на сервере вообще.

Вот подробности — ru.nuxtjs.org/guide (возможно, понадобится включить VPN)

Не знаю как Коля, а у меня вообще статический HTML генерируется Node, и потом отдаётся Nginx.

Дальше подгружается JS и начинает работать всякий динамический функционал. То есть, весь фронтенд рендерится на сервере и сохраняется в HTML + JS, а дальше только запросы в API за актуальными данными.

Соответственно, фронтенд можно хоть на Github.io хостить и генерировать при новом PR в Git, а бэкенд на отдельном сервере — и никаких проблем.

То есть, если я пишу бэкенд на JS и запускаю его на Node — то это не Node?

Этот бэкенд точно так же, как и PHP, примет запрос, залезет в БД и выдаст JSON ответ.

На фронтенде вообще никто не поймёт, на чём именно бэкенд написан, потому что снаружи будет видно только Nginx, а всё остальное проксируется или в Node, или в php-fpm.

Так в чём разница-то?

А есть разница?

Раян Дал. Создатель NodeJs.

Не работает с NodeJS где-то с 2012-2013 года. Дал это интервью в 2017 году.

Прям надо бросать всё и бежать на Go.

Но если вы пишете распределённый DNS сервер, я бы не выбирал Node.

А, так он вот про такой сервер говорил?! Не про бэкенд для веб-сайта?

Потому что php никогда не станет помощником на фронтенде, а вот js научился работать на сервере.

JS еще научился собираться в нативные мобильные приложения для Android и iOS, например через React Native.

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