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

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

С нами с 31 января 2013; Место в рейтинге пользователей: #3
Сергей Шлоков
17 января 2022, 21:28
0
Кстати есть ли возможность проверить используется ли на странице где то стандартный парсер?
Он используется всегда.
Сергей Шлоков
17 января 2022, 10:46
0
Смешанный режим — это зло. Даже опытные разработчики путают последовательность при работе в этом режиме. Сначала работает феном, потом стандартный.
Сергей Шлоков
17 января 2022, 10:45
0
Вроде была статья. Но в ней как раз и писали, что феном не даёт прирост скорости. В документации есть тест по pdoTools. Вот он даёт. А феном — это лишняя нагрузка. Он не заменяет стандартный шаьлонизатор, а дополняет. Т.е. работают 2 шаблонизатора. Кроме того, кэшируемые теги MODX, написанные на феном, MODX переводит в свой формат (дополнительная нагрузка). Чтобы было понятно — кэшируемый тег MODX на странице превращается в результат и при следующем запросе страницы уже не вызывается (он распарсен). А феном тег остаётся и MODX должен дополнительно его обработать, перевести в MODX формат и проверить кэш.
Ну и плюс ещё разные неувязки. Я уже много раз о них писал.
Сергей Шлоков
17 января 2022, 06:46
+1
Ну тут он будет полезен новичкам, или если нашёл где то решение в интернете или в документации, а там родной синтаксис, быстро его перевёл.
Хотел бы я посмотреть на такого новичка. Уверен, такого не найдётся.

Ещё раз повторю — феном имеет смысл использовать только ради его функциональных возможностей. Простая смена синтаксиса вызовов чанка или сниппета не только лишние затраты по времени, но и негативно сказывается на производительности сайта.
Сергей Шлоков
16 января 2022, 08:28
0
По-моему, просто достаточно примера как перевести теги чанка, сниппета и плейсхолдера из MODX формата в Fenom. Что-то типа cheat sheet. Ибо данный вариант сервиса способен переводить только простые конструкции.

У Fenom больше возможностей. Например, в параметрах можно указать число, массив, сделать конкатенацию. Также различные управляющие конструкции. Этого нет в MODX синтаксисе.

А банальный перевод тега на Fenom (просто чтоб было) ничего не даёт. Даже хуже — MODX теги работают лучше и меньше нагружают парсер.
Сергей Шлоков
15 января 2022, 19:12
0
Ничего не могу сказать. Я первым делом тестирую на своем сайте. Обновилось без проблем.
Сергей Шлоков
15 января 2022, 19:10
+1
Fenom, даже если и влияет на скорость сайта, то совсем не в положительную сторону. Вот сам pdoTools да. Там много чего оптимизировано по сравнению с кодом MODX.
Сергей Шлоков
11 января 2022, 21:14
0
Я склоняюсь к решению, которое я сделал в ZoomX — возможность указывать несколько путей для файловых элементов. В сторонних компонентах нужно будет использовать плагин на событие «pdoToolsOnFenomInit».

В любом случае, во второй версии эти параметры просто задепрекейчены. В третьей (которая для MODX3) они удалены.
Сергей Шлоков
09 января 2022, 15:15
+2
Это нереально и бессмысленно. Если только в качестве сервиса — ввёл тег MODX, получил варианты на Fenom. Потом вставил куда надо.
Сергей Шлоков
09 января 2022, 08:51
+1
Собственно, наблюдая за тем как развивается MODx, у меня складывается впечатление что очень многое из того над чем сейчас работают люди, это либо мало кому будет нужно, либо уже совсем неактуально в свете последних тенденций рынка web-разработки.
Сергей попытался внести в MODx чуть-чуть современного подхода к бекенду, но большинству сайтоделов на MODx оно нахер не всралось. В чем я не прав-то? Я уже молчу про то, что на рынке эти инструменты которые создаются для MODx не востребованы, как и сам MODx.
Конечно не растут, потому что сам MODx в стагнации уже много лет и единственные кто его до сих пор держат на плаву, это единицы разработчиков платных дополнений и сам стерк, у которых бизнес на нем завязан.
Людям дали инструмент. Но любой человек который перешагнул по навыкам и знаниям MODx, уйдет в более современный и востребованный на рынке инструмент. Вон тут уже упомянули Laravel.
Тут лишь остается рассматреть вариант сборки сайтов на MODx в кач-ве фриланса. Вариант конечно имеет место быть, но крайне спорный… Лучше уж взять хороший фриланс заказ и создавать его на микросервисной архитектуре, используя современные инструменты.

Дискуссия. Много полезной пищи. Ещё больше её в комментариях про клиентов-лохов.

Вишенка на торте — «Баллада о железном слове» (мы в молодости называли это вагина-мяч) в двух актах.
Акт 1.
Да я могу целый список составить того, почему UI в MODx плохой и это будет не субъективная оценка, а отзывы которые я собирал годами от своих клиентов.
Акт 2.
Конечно я не буду тратить время на сбор списка причин, почему UI/UX админки в MODx плохой.
Занавес.

П.С. Всё сказанное про медленное развитие MODX верно. И про PR, висящие годами. Многие из нас уже мозоль на языке натерли говоря об этом. И я в первых рядах. Но на сайте сообщества MODX рассказывать про то, что сайты нужно собирать на микросервисной архитектуре, это уж как-то… Для таких новаторов нужно особые ресурсы создавать.

П.П.С. Всё вышесказанное Павлу прошу читать вежливо и с уважением, ибо мы знаем друг друга давно и просто спорим. )
Сергей Шлоков
08 января 2022, 10:00
0
Т.е. обещанного списка отзывов, собираемых годами от клиентов, не будет? Мда. Вот и всё, что нужно знать о холиварщиках. В лучшем случае (это в самом лучшем случае) получите список ишу Руслана Алеева про пермишены.

Да, и ещё, совет заказчикам — когда разработчик начинает нытьё о глюках дерева при большом количестве ресурсов, задумайтесь о его проф. пригодности.
Сергей Шлоков
07 января 2022, 13:29
+5
Не воспринимайте как критику.
Почему? Критика бывает более полезна, чем восторженные отзывы.

Такие надстройки (так как их делают программисты для себя и других программистов) делают MODx более сложным.
Правильно ты пишешь про программистов. А для них как раз ничего сложного нет. Это дополнительный инструмент для работы, а не обязательная замена. Раньше, чтобы так кодить, нужно было уходить во фреймворки. Сейчас также можно работать и в MODX до какого-то момента. Разве это плохо?

Закреплю посыл — ZoomX не для массового использования. И, кстати, изначальная задумка была для замены MODX шаблонизатора. Идея навеянна Evolution CMS. Но ребята ядро переписали под Laravel. С MODX это невозможно. Поэтому и дополнение. А потом решение стало обрастать правилами фреймворков. Именно поэтому мажорные версии. Но при этом концепция CMS никуда не делась и новичкам ничего не нужно заново учить. Т.е. ZoomX позволяет как бы растянуть момент покидания MODX.

Уникальность MODx как раз в простой и удобной админке, в простом создании ресурсов, отображении их в виде понятного дерева с понятным редактированием этих ресурсов из админки. Доступ к шаблону из самого ресурса.
ZoomX ничего этого не меняет. Он меняет только правила шаблонизации. Один проход. Как это принято не только во фреймворках, но и в других CMS. Подход MODX с многократной обработкой регулярными выражениями себя (в наше время) не оправдывает. А PHP шаблонизаторы компилируют код, оптимизируют его за счёт Opcache. Это даёт и гибкость и скорость.

С приходом таких дополнений, как ZoomX, нужно прописывать роуты, а создание ресурса превращается в написание кода. Это вряд ли привлечёт большое количество новичков в MODx (именно эта категория пользователей даёт популярность таким проектам, как Wordpress).
Задача ZoomX не привлечь новичков, а удержать старых разработчиков. А если бы ты попробовал его или хотя бы прочитал доку, то не писал бы такое. )
Сергей Шлоков
07 января 2022, 11:03
0
Да я могу целый список составить того, почему UI в MODx плохой
Составь. Уверен, все только спасибо скажут.
Сергей Шлоков
04 января 2022, 08:54
0
Как сказал Николай, в MODX3 мажорные изменения. Теперь работа организована через композер и все классы имеют неймспейс. А дополнения для MODX2 работают с классами без неймспейса. Поэтому они нормально работать в тройке не будут.
Сергей Шлоков
04 января 2022, 08:47
0
Бывает на апаче на сайте с отсутствующей favicon.ico.
Сергей Шлоков
28 декабря 2021, 11:57
+2
Ну докрутить ещё маршрутизацию (middleware, имена роутов) + нормальный контейнер зависимостей и будет очень близко (если не сравнивать xPDO и Eloquent). Ну ещё аутентификацию для API.
Сергей Шлоков
18 декабря 2021, 12:43
+1
Спасибо, что тестируете!
Сергей Шлоков
16 декабря 2021, 21:29
+2
Спасибо за помощь в тестировании!
Дело в том, что tplOuter также является и шаблоном для tplInner, если последний не указан. А по умолчанию он пустой. Поэтому так и получается.

Вот тут можно подробнее почитать про параметры сниппета pdoMenu.

Сергей Шлоков
14 декабря 2021, 19:34
0
Это сделать абсолютно не сложно. Добавлю в следующей версии. Просто интересно, зачем дебажить сразу 2 вызова одного и того же сниппета?