Class yii\validators\NumberValidator

[Ale}{]

Столкнулся с такой вот ситуацией - атрибут может быть только числом (с запятой) - поставил в правиле

Код: Выделить всё

[['summ'], 'number']

Все работало, пока пользователь не ввел число такого типа '23.' - т. е. разделитель дробной части указал, а саму дробную часть нет- валидатор не пропустил - указав что это не число.

Считаю это багом. Какие мнения?

[ElisDN]

А 23. - это число?

[Ale}{]

число)

[ElisDN]

И .5 число?

[Ale}{]

кстати где такую запись тоже встречал))
и вот тут погуглил немного http://gimn1567.ru/metod/less_qb/6.htm

.5 - нормальная запись дробного числа на Basic) может от туда и пошло

попробовал на PHP

Код: Выделить всё

$a=.8;
    $b=2.;
    $result=$a+$b;
    var_dump($result); 
    
    Выдал float(2.8)
    

ну дело даже не в этом - а в том что на клиенте число типа '23.' при применении к нему форматера на JS представляется как 23.000 - а вот хранится оно как ' 23.' - и было оно занесено в поле табличной части документа - долго искал почему валидация не проходит(

PS 0.(3) - тоже число) - (3)- означает в периоде)))

[ElisDN]

Ну а храните такие числа Вы где?

[ElisDN]

Ну а так добавьте преобразование:

Код: Выделить всё

[['summ'], 'filter', 'filter' => 'floatval'],
[['summ'], 'number'], 

[Ale}{]

да дело не в том, как исправить именно мой код)
Я вообще вынес на обсуждение такой вопрос (Ветка то называется "Баг-репорты и предложения (Yii 2.x)") - и на правильность только моих рассуждений не претендую.
У себя то я ситуацию исправил)

php даже вот так нормально отрабатывает

Код: Выделить всё

$a=-.8;
$b=2.;
$result=$a+$b;
var_dump($result);

Результат float(1.2)
 

[Ale}{]

Ну а так добавьте преобразование:

Код: Выделить всё

[['summ'], 'filter', 'filter' => 'floatval'],
[['summ'], 'number'],

не совсем идентичная логика тогда получится)

до внесения фильтра - модель выкинет ошибку и скажет что внесли не число - это то что мне и нужно!

А если сделать как у тебя - то любую строку на входе оно преобразует в число , дальше валидатор number - бесполезен) и ошибки никогда не будет по данному атрибуту

[ElisDN]

Ну да.

[Ale}{]

Дальше если развить тему - смотрим на

Код: Выделить всё

public string $numberPattern = '/^\s*[-+]?[0-9]*\.?[0-9]+([eE][-+]?[0-9]+)?\s*$/'
 

То есть предусмотрен только разделитель в виде '.', на мой взгляд можно предусмотреть и получение данных с разделителем ','
И если пришел с разделителем ',' то преобразовать его для машины в '.'

[Ale}{]

и еще мысли по поводу записи чисел в виде '.5', '-.5', '5.' - конечно от пользователя это крайняя редкость получить числа в такой записи (хотя '5.' - может быть распространено - машинально вводят дробные числа и машинально ставят '.' и в случае отсутствия дробной части - ничего не вводят).
Но если модель будет создаваться внутри приложения - и какой-нибудь "умный" присвоит полю модели число в таком виде - то модель валидацию не пройдет(

[ElisDN]

А потом Вам ещё приспичит комплексные числа и дроби вводить...

[Ale}{]

Я исхожу из того, что если сам язык PHP принимает такие записи чисел, то и валидатор должен их принимать

[samdark]

В контексте языка это лоично. В контексте приложения, то есть с точки зрения не программиста — не очень.

[Ale}{]

Ну так дело в том, что ввел такое число пользователь)

[zelenin]

В контексте языка это лоично. В контексте приложения, то есть с точки зрения не программиста — не очень.

то есть пользователю логично угадывать паттерн, который примет у него приложение?
Логично давать возможность ввести паттерн для валидатора как минимум (возможно такая фича уже есть). А программисту нормализовать пришедшие данные до БД-формата.

[Ale}{]

В контексте языка это лоично. В контексте приложения, то есть с точки зрения не программиста — не очень.

то есть пользователю логично угадывать паттерн, который примет у него приложение?
Логично давать возможность ввести паттерн для валидатора как минимум (возможно такая фича уже есть). А программисту нормализовать пришедшие данные до БД-формата.

переопределить регулярное выражение есть возможность)
но я завел тему для обсуждения внесения изменений в регулярку на уровне фреймворка

[samdark]

В разных проектах требуется разная валидация. Сейчас там вариант для наиболее широкой аудитории. Не программистов и не математиков. Если нужно принимать комплексные числа, валидатор поддерживает изменение регулярного выражения.

[Ale}{]

о комплексных числах речь вообще не идет)