2 часа назад
Благодарю за ответы.
Обновил Minishop2 с 2.5.0-pl до 4.4.0-pl., заказы не приходят на почту 3
16 ноября 2024, 21:12
Спасибо. Работает.
Не процессится значение TV в шаблоне pdoPage при передаче его в сниппет кастомный. 2
16 ноября 2024, 20:54
Владимир, добрый день!
Есть возможность добавить в модуль функцию отмены заказа?
Т.е. если в админке магазине поставили статус Отменен, чтобы в Ти...
[mspTinkoff] 1.0.2 — Новое API + ККТ 54
15 ноября 2024, 17:40
спасибо, несколько раз проверял и не заметил)
pdoResources не выводит ресурсы с указанным шаблоном 2
14 ноября 2024, 13:55
Сложна.
Я сделал с помощью js. Задал class для div c results
и вот так прописал
document.querySelector('.easycomm div').textContent = 'Отзывов пок...
Как правильно задать свой блок "Ничего не найдено" в mFilter2 7
14 ноября 2024, 11:50
Добрый день! Установил MarkdownEditorFrontend с modstore и xpdo выдало ошибку что не может найти сервис. К моему удивлению в транспортном пакете не на...
Markdown - редактирования текст в формате markdown 11
14 ноября 2024, 05:22
astro.build впервые слышу такой фреймворк. Вообще gtsAPI затачивался под primevue.org. Но в primevue вообще не никакой связи с api. Там api как хочешь...
gtsAPI - Универсальное API для MODX 4
13 ноября 2024, 10:55
Не все пожелания клиента нужно реализовывать. Одно дело когда желание обосновано бизнес-процессами, а другое дело клиент так видит. В данном случае, н...
Как правильно сделать авторизацию двух разных групп пользователей. 5
13 ноября 2024, 10:28
Файл: core/components/msearch2/phpmorphy/src/fsa/access/fsa_sparse_file.php
Перед строкой 32 добавить:
if(!is_array($word)) {
$word = (a...
mSearch2 приводит к заполнению журнала ошибок (mSearch2 fills error log) 1
12 ноября 2024, 19:52
С ним славу богу все хорошо. Он пошел дальше по карьерной лестнице, оставил MODX позади и сейчас заглядывает к нам только поздороваться.
Не могу справиться с fullCalendar"ем 7
Всего 123 794 комментария
Но проблема в том, что конфиг генерируется во время рендера страницы. Так уж задумано. Я подумаю как можно облегчить такие задачи в будущем
Установил 3.0.3 поверх 2.8.5, админка перестала работать сразу. Просто ни одна кнопка не работает и всё. В консоли — куча ошибок.
После выполнения трюка с заменой Om часть русских букв появилась, остальное — так же нечитаемо. Админка осталась мёртвой.
Я согласен, что это не самое удобное решение, но вынужден повторить — в моей практике нечасто встречаются кейсы требующие манипулировать значениями перед отправкой, поэтому я и не добавил дополнительных событий.
Нет, лозунг был другой: одна отключаемая зависимость лучше двух обязательных.
Потому что счёл его риторическим, логично же что никаких работ по усовершенствованию не ведётся, разработан новый API и его развивают.
Ты меня за идиота принимаешь? Я решаю возникающие у меня задачи, удобным для меня способом. Мне нужно показывать процесс загрузки, Fetch API этого не умеет, я использовал XMLHttpRequest. По-моему всё логично.
Мне кажется ты упускаешь суть: ты писал компонент с целью внедрения Fetch API, я писал компонент с целью повысить удобство собственной работы и отказаться от использования jQuery. Не вижу причин по которым я обязан был использовать Fetch вместо XMLHttpRequest. Для пользователя компонента это вообще не важно, что там под капотом, главное это стабильное выполнение необходимых ему функций.
И наконец, всё что ты перечислил в качестве проблем AjaxFormitLogin, всего лишь твоё скромное мнение, о чем ты забыл упомянуть, отчего кому-то может показаться, что перечисленные тобой «проблемы» действительно серьезно могу усложнить жизнь пользователю моего компонента. Я думаю тот, кому понадобится больше событий и API, легко поймёт, что всё это есть в FetchIt, и выберет именно его.
Хорошо, ты не смог придумать, а я представь — смог. Тык, тык и тык.
Прости, но мне придётся поязвить — ты же обязательно покажешь как расширить класс? Т.е. для простой задачи добавить и/или изменить значение в форму перед её отправкой, нужно манипулировать с DOM или расширить класс? Прикольно.
Я уже понял. Именно с этим лозунгом ты сменил jquery-form на XMLHttpRequest
Ты проигнорировал вопрос про асинхронность в XMLHttpRequest, но это приводит к более веселой ситуации: А когда в XMLHttpRequest появится (спойлер — не появится, но есть библиотеки-обёртки над ним в которых реализована асинхронность) ты обратно перепишешь с Fetch API на XMLHttpRequest?
Грубо говоря да, но при желании всегда можно расширить класс.
Нет смысла обновлять то, что и так работает.
Понятное дело не использовать подключение зависимостей через cdn.
Когда такая возможность появится — перепишу.
Добавление и/или изменение значений отправляемых на сервер, например. Или ты хочешь предложить манипулировать DOM для этого?
Ну мне то объяснять уж не стоило. Ответ на вопрос «Почему?» я знаю, тут другой несколько вопрос «Зачем?». Каждый раз когда зависимость обновиться, нужно будет обновить компонент? Ну прикольно. А еще бывают «прикольные приколы», когда разработчик sweetalert2 захочет выразить свой личный протест в OpenSource проекте, то как быть с этим?
Тут важно, не каждая зависимость это плохо, но это тот самый случай, когда легко и безболезненно можно обойтись и без него.
Позиция ясна. А это единственная причина? Fetch API пока не позволяет. Но знаешь в чём загвоздка? Работа над введением этой возможности ведётся и оно точно появится, а ведётся ли работа над асинхронностью в XMLHttpRequest?