var isFormPrepared = false;
$('form').on('sumbit', function(ev) {
var form = $(this);
if (!isFormPrepared) {
ev.preventDefault();
$.post({
...
}).done(function(result) {
form.find('[name="label"]').val(result.label);
form.find('[name="targets"]').val(result.targets);
isFormPrepared = true;
form.submit();
})
}
})<form method="POST" action="https://money.yandex.ru/quickpay/confirm.xml">
<input type="hidden" name="receiver" value="41001xxxxxxxxxxxx">
<input type="hidden" name="formcomment" value="Проект «Железный человек»: реактор холодного ядерного синтеза">
<input type="hidden" name="short-dest" value="Проект «Железный человек»: реактор холодного ядерного синтеза">
<input type="hidden" name="label" value="$order_id">
<input type="hidden" name="quickpay-form" value="donate">
<input type="hidden" name="targets" value="транзакция {order_id}">
<input type="hidden" name="sum" value="4568.25" data-type="number">
<input type="hidden" name="comment" value="Хотелось бы дистанционного управления.">
<input type="hidden" name="need-fio" value="true">
<input type="hidden" name="need-email" value="true">
<input type="hidden" name="need-phone" value="false">
<input type="hidden" name="need-address" value="false">
<label><input type="radio" name="paymentType" value="PC">Яндекс.Деньгами</label>
<label><input type="radio" name="paymentType" value="AC">Банковской картой</label>
<input type="submit" value="Перевести">
</form>Делаешь orderBy + where за последние двадцять дней. То, что ты бы делал и без твоей говно-групировки, только быстрее и проще.
Что за бред? Человек делает АПИ, а не монолит с рендерингом на сервере. У него приложение - SPA, которое само по себе АПРИОРИ JS. И momentjs, весом в 22кб gzip, в сравнении с всем фронтовым приложением не весит нихрена.
Еще вопрос: что если тебе нужно в одном запросе отправить две даты: одна от юзера, а вторая - с какого-нить гуглосервиса в UTC. Будешь делать на каждую дату по параметру? Или конвертить гуглодату по оффсету в юзерскую дату, а потом на беке снова назад? Или второй параметр ignore?
future proofing - не, не слышал
Конечно не нужен. Кому нужны индексы? Кому нужна гарантия целостности данных?
Извини, но это хуйня какая-то.
он, в примере, необходимо сгруппировать данные по дате с учетом таймзоны клиента. Предположим, а таблице с данными 100000 записей. Их все на клиент перекинуть и там группировать?
Вернется то 100 тысяч записей что с группировкой, что без, и перекинуть нужно будет сто тысяч в обеих случаях - в чем разница?
Лол. То есть отдавать одни и те же данные дважды, просто потому что фронту лень работать с датами? От бека идет минимальный нужный набор данных. Данные от бека должны быть МАКСИМАЛЬНО независимыми от фронта.
Мда. А давайте ка придумаем велосипед, которым ОЧЕНЬ УДОБНО пользоватся, а так же забудем о консистентности (в каждом запросе одни и те же данные могут означать разные вещи - что есть пиздец), ради того, что бы.. что бы что? Я так и не понял, нахрена так делать.
Именно негласный. Точно такой же, как и хранение дат в UTC в базе, а не в чем-то другом. Или использование utf8mb4 вместо utf8/любой другой в mysql. Или расстановка foreign ключей. Или тайп-хинтинг + var аннотации. Продолжать?
использование utf8mb4 вместо utf8/любой другой в mysql.
расстановка foreign ключей
тайп-хинтинг + var аннотации
Ну да, почему бы и нет - покрыть весь проект raw'ами и разгребать это говно через годик :)
Это известный и вполне рабочий подход.
Да ну? Известный где, в твоих проектах?
И как это не относится? Код НУЖНО писать хорошо. Примера вверху это не касается. Даже и близко. СОВСЕМ.
это твой говнокод выше с имитацией json'а. Я вообще в ахуе, что кому то пришла такая идея в голову.
Я не могу сделать так:
1.Нажатие на кнопку
2.Изменение значение переменной
???
имейте уважение к чужому времени. Вам дали наводку, поискать могли и сами.
В сообществах полно информации почему не стоит хранить часовые пояса в БД.
The Problem with Time & Timezones - Computerphile
Что должен знать о времени каждый программист
при этом принимать таймзону как параметр
- может. Вопрос - нахрена?
Где ответ на вопрос с публичным АПИ? Будете к каждому запросу лепить таймзону как параметр?
Еще вопрос: как будете выводить дату, если по ТЗ нужно вывести ее в двух часовых зонах - локальной и по Moscow? Ваш лучший вариант - спарсить дату в указанной таймзоне momentjs'ом, предварительно указав таймзону, и засетать Moscow. Консистентность? Не, не слышал.
Еще вопрос, который я уже задавал: каким образом будете фиксить неправильное время на ПК клиента? Вы можете гарантировать, что у каждого, кто пользуется вашим фронтом, будет верное время? Нет? Каким образом будете компенсировать? Добавлять ВТОРОЙ параметр, помимо таймзоны, типа offset и указывать кол-во часов-минут?
Это негласный стандарт, конечно же. Такой же, как и ХРАНЕНИЕ дат в UTC.
это даже и близко не то, что хочет автор. Ему нужно выделить разные ключи, а вы делаете group by по СУБД, который к этому не имеет никакого отношения
Кроме того, если у вас есть нужда писать ТАКОЕ (три функции, пять параметров) - значит вы что-то делаете не так.
SELECT
RIGHT(LEFT(CONVERT_TZ(`date`, '+00:00', '+10:00'), 10), 5) AS 'day',
CONCAT('[', GROUP_CONCAT(JSON_OBJECT('id', `id`, 'date', `date`)), ']') AS 'data'
FROM
`news`
GROUP BY
RIGHT(LEFT(CONVERT_TZ(`date`, '+00:00', '+10:00'), 10), 5)
мешают стандарты, принятые в разработке.
АПИ не должно быть привязано ни к какому юзеру, и, следовательно, никакой таймзоны он не знает.
Стандартизация. Везде UTC. Потому что так проще всем.
А так мы в явном виде выполняем тернарник, сохраняем результат этого выполнения в переменную с нормальным названием и потом используем эту переменную.