30 сентября 2019 в 16:09
form api #type' => 'number'
Подскажите, как заставить не ругаться на десятичные знаки "." и ","
Вообще задача дать возможность писать пользователям в ajax форме оба разделителя, но ругается валидация.
Комментарии
Реплейсить по кейапу в своем скриптике вариант?
Автор прав в своем желании дать возможность писать оба варианта.
Точки они тут только у программистов. У всех Российских обычных людей в школьной программе десятичным знаком была запятая, в калькуляторах - запятая, в икселе - запятая, в градусниках - запятая.
То что друпал ругается на запятую - это проблема вашей "дурацкой программы". И нужно не клиента учить, а самим научиться подстраиваться под клиента - это и есть "юзер френдли".
Если реплейсить по кейапу, то клиент, печатая запятую, будет видеть точку. Уверен он подумает, что ошибся, сотрёт её и попробует снова. Или, о боже, решит что у него раскладка включена латинская и начнёт переключать её. И квест продолжится...
Пользователь должен видеть то, что он ожидает увидеть. Если нужно что-то зареплейсить, то это лучше делать прямо на сервере либо непосредственно перед отправкой.
"дебильный" '#type' => 'number' делает правильно, что использует запятую.
Просто стало скучно и захотелось по-холливарить?
Не вижу источника холливара. Я аргументировал замену кейап на сабмит.
Аргумент более на скупую претензию к моему вопросу похож. Может из-за всех этих ваших оценочек, вроде "дурацкий" и "дебильный".
Сабмит так сабмит, я не против.
Искренне прошу меня извинить, bumble, если это прозвучало как претензия. "дурацкий" я использовал от лица пользователя для театральной наглядности в целом к айти, а "дебильный" это цитата из сообщений ниже. Согласен, аргументацию нужно было подсушить.
Без проблем, не стоит извинений. Недопонялись...
str_replace при расчетах не помогает, потому как ошибка раньше. Вроде и считает, но как то непонятно, то есть результат то нет.
PS. Ну да, реплесить надо было раньше, в validate, а не в калбеке
<?phppublic function validateForm(array &$form, FormStateInterface $form_state) {
$max = $form_state->getValue('max');
$max = str_replace(',', '.', $max);
$form_state->setValue('max', $max);
}
?>
Выкинуть нафиг это дебильный html5 - type="number"... Не мучайтесь, он ни в одном браузере не стандартизирован.
И сделать как bumble говорит, только на textfield.
Типа того:
this.value = this.value.replace(/[^0-9\b.,]/g, '');
this.value = this.value.replace(/,/g, '.');
});
Получается что вот это самый верный вариант.
нууу... условно верный. Он не ограничит варианты типа "....5...45.9..."
На такие значения друпаловская валидация (php) отработает.
Я к тому, что раз уж всё равно на фронте делаете проверку поля, то почему бы её не сделать чуть лучше? Посчитать кол-во точек ведь не сложно )
ИМХО, не надо делать никаких проверок на фронте. Сугубо косметический (юзерфрендли) характер и не более. Все проверки должны быть на бэкенде.
Если все же хочется жесткие условия в jquery, то проще готовые скрипты подцепить (разновидности mask и т.д.). В любом случае вы их будете валидировать/реплейсить на бэкенде.
В форму можно очень просто передать любые значения, игнорируя скрипты. Полагаться на фронт - это недальновидность (имхо).
Недальновидность - предполагать, что кто-то отказывается от валидации на бэкенде.
И мы ведём речь, сугубо, о косметическом характере, ведь заменить запятые на точки можно и в бэкенде, не так ли?
Так ли... но борьбу с type="number" - это никак не решает.
В этой ветке, мы отказались от type="number" и нет никого смысла бороться с ним здесь.
Знак, скорее всего, зависит от локали. Допускаю, что если добавить атрибут lang="en" в input элемент, будет форсироваться точка. Как это влияет на то, в каком виде отправляется на сервер - хрен его знает. Как оно себя ведёт в разных браузерах - надо пробовать.
Оптимальней использовать обычный text и добавить свою валидацию.
Я давеча на реакте форму какую-то делал и очень удивился, что type="number" принимал и точку, и запятую, и корректно это дело сохранял. Я уже не помню, в чём там был подвох, но я был удивлён.
Что касается возможной замены на обычный текстовый инпут, нужно учитывать, что трафик с мобильных устройств на многих сайтах уже перевалил за половину, а тип инпута определяет, какая клавиатура появится при фокусировке. Согласитесь, что с мобилы набирать цифры на цифровой клавиатуре значительно удобнее. И ещё нужно учитывать, что типы email и tel тоже имеют свою специфическую клавиатуру.
Поэтому оптимальным решением будет ловить ввод через js и заменять разделитель на правильный.
Да в браузерах всегда подвох.
Солидарен с email и tel. Они вполне юзабельны в html5.
Все же оптимальным будет отталкиваться от того, как данные хранятся в бд. Особенно по телефону, суммы транзакций и т.д. Или это только про точку речь?
P.S. Единственное, что хорошо в number - это реализация "штучного" поля. Атрибуты min, max, step - тут полезны.
Да и то, в лисе внешний вид этого поля убогий (имхо).
Нет смысла отталкиваться от того, как данные хранятся в базе, т.к. на элементе уже есть валидация, которая всё преобразует в числовой формат, поэтому нужно только поменять разделитель на вводе, чтобы юзер не забивал себе голову.
Что касается разного вида в разных браузерах, то эти стрелочки можно выпилить в цсс.
Давай так:
Какая валидация отработает раньше: браузерная или джимкери с точкой?
А если нужно оставить стрелочки, но не страхожопные (с примером желательно)? Иначе в чем тогда смысл number?
Естественно, js. Жквери должен срабатывать на изменение данных в инпуте, а браузерная валидация работает только на сабмите формы. Кстати, на друпаловских аякс-формах браузерная валидация не срабатывает, т.к. событие submit блокируется.
В чём смысл поля number - я уже писал выше.
Ну да, не прав, жквери раньше. У меня pattern стоял, который на-лету ругается на значение (хром). Без паттерна норм все.