9 часов назад
Да, пожалуй именно это и верно, спасибо. Вопрос снимается.
Обновление рейтинга пользователей на MODX.pro 9
Вчера в 12:11
Аналогичный вопрос: есть перечень опций формат бумаги: А2, А3, А4, надо добавить в этот перечень поле «ваш размер» с возможностью ввода текста пользов...
[msOptionsPrice2] - Модификации продукта. 373
04 января 2025, 17:18
Методом тыка просто убрал
data-si-form data-si-event="change"
и в итоге стало вот так
<select name="sort_by" form=&qu...
Sendit и Pagination 6
27 декабря 2024, 15:56
Ух, класс! Вот так работает:
$array = array(111, 112);
if(in_array($modx->controller->resource->get('id'), $array)) {
$modx->regC...
RTE для introtext: помогите пожалуйста с подсказкой 7
27 декабря 2024, 13:50
Огромнейшее спасибо! Работает.
PageBlocks. Удобное управление контентом сайта. 41
26 декабря 2024, 12:43
А как вы в шаблоне письма вывели имя пользователя? У меня просто в шаблоне отрабатывает. А в письме нет.
[[$user.name]]
[[$us...
Sendex - как добавить поле "Имя"? 2
26 декабря 2024, 11:10
Слышу эту песню про программирование — уже с лет 20 точно.
Но пока «мы» даже сверстать макет не можем автоматически, чтобы можно было в продакшен о...
Испытание ИИ Cursor 9
25 декабря 2024, 14:13
В итоге переписала сама. Не знаю можно ли вставлять сюда столько текста, так что чистый JS код, если кому надо, можно найти по ссылке
[xLike] Идеальная система лайков с оптимистичным интерфейсом и правильной формулой 113
24 декабря 2024, 21:46
Это не косяк, это осознанное изменение. Я считаю, что нет смысла показывать «Форма содержит ошибки» и ещё сами ошибки. Однако само сообщение в ответе ...
[SendIt 2.0.0] Пагинация и обновлённая загрузка файлов 28
23 декабря 2024, 18:04
Для версии 3 лучше конечно иметь типа minishop3.
Да для всего этого нужно свободное время конечно же.
minishop2.com. Почему то не хочет в админку сайта заходить 3
Я в своих проектах для решения подобной задачи просто использую DSL (Loopback 4), который нивелирует разницу между выбираемой технологией под абстаркцию описания типов (по аналогии, как это делается в MODX, когда описывается схема таблицы в XML). В этом случае мы сможем решить ещё и проблему поддержки нескольких типов БД — MySQL, PostgreSQL, NoSQL.
Веб-воркеры, сервис-воркеры, сокеты, модули, PWA, работа в оффлайне и т. д. — всё то, что будет иметь каждый конкурентный продукт в ближайшие годы. Конечно, все эти технологии не должны навязываться выбранной CMS/CMF-системой, но ещё хуже, когда они противоречат.
Восстребованной будет та система, которая минимизирует время + ошибки + порог вхождения + тестирование и отладку + кастомизацию и/или расширяемость. Я использовал 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.
Так это не имеет отношения к MODX. Вон на nevatrip.ru у меня 100k записей, а оптимизацией даже не занимался ещё.
А вы попробуйте использовать «Битрикс-подход» к этой проблеме — оплатите работу профессионала. Уверен, будет дешевле аналогичного решения от 1С.
Потому что «взять и переписать» звучит для них гораздо страшнее, чем «мы оставим всё, как есть, но теперь ваши странички будут открываться быстрее и без перезагрузки».
Потому что MODX хоть и достаточно монолитный (в сравнении с всякими Phalcon'ами, Laravel'ами и прочими Yii на composer'ах), но значительная часть архитектуры более чем оправданная, особенно учитывая, сколько времени CoreTeam поддерживает обратную совместимость 2.x-поколения.
Конечно, многое зависит от опыта и «базы» — я пришёл в разработку именно благодаря MODX, он (она?) обеспечил планомерный и правильный «вход в профессию» („Привет!“ «разработчикам мышкой» на WordPress). Тем, кому «повезло» больше и имеет за плечами фундаментальные знания паттернов, алгоритмов и других «интегралов», конечно, сподручнее использовать что-то более низкоуровневое, но это не принижает заслуги MODX и сообщества.
Сейчас у меня есть удачный кейс, когда шаблонизатор отделён от данных дополнительным слоем абстракции, где происходит нормализация и весь шаблон на выходе имеет JSON-структуру, на которую применяются чистые функции. Что это даёт (при наличии опыта и понимания):
* отделение логики от представления, возможность фронт-енду и бэк-енду работать параллельно и независимо, использование mock-объектов для данных, если сервер ещё не готов, бэк-енду не нужно думать о том, как «сверстать всё это, чтобы было красиво» — он работает над правильной архитектурой;
* более высокая скорость отдачи страницы на клиент (да, MODX можно ещё ускорить, и от этого аж уши закладывает!), при этом рендер по-прежнему происходит на сервере (привет, SEO), а при правильном выборе шаблонизатора, код может быть изоморфным — получаете SPA-приложение «из коробки» (те самые «реактивные интерфейсы»). Если не ошибаюсь, Николай @real-Fi1osof Ланец неоднократно рассказывал, что шаблонизатор MODX — bottleneck производительности;
* реиспользование. У MODX в этом плане пока слабо, он довольно монолитный, но фронтендовский компонентный подход во всей красе.
Из возможных минусов: наиболее быстрый шаблонизатор сейчас написан на JavaScript, попытки переписать XJST на PHP, Python и даже Go потерпели фиаско. Сейчас JS, де-факто, стандарт в мире фронт-енд-разработки (рубисты больше не фыр-фыр), т. е., конечно, я не предлагаю начинающим разработчикам делать лендинги на таком стеке, но любой более-менее сложный конкурентный (!) проект, который вы планируете поддерживать или цикл разработки которого больше 5-6 месяцев неизбежно будет обрастать легаси-кодом и лишь правильная декомпозиция позволит этого избежать.
Т. е., если рассматривать MODX исключительно как админку + RESTFul API-сервер, можно наконец-то забыть об оверхеде переноса и отладки клиентской части сайта/приложения на MODX, потому что MODX будет заниматься только тем, чем и должен заниматься бэкенд — данными, не тратя время на шаблонизацию.
— lavkaschastya.com/
— www.schastye.com/
React, нестандартные наборы товаров, вёрстка любой сложности. Хочу ещё попробовать полностью отказаться от MODX-шаблонизатора, но подходящего проекта пока не было.