Согласен, однако внятный сбор ошибок валидации тут присутствует. И при грамотном использовании его внятность куда выше чем у описанных вами библиотек, хотя фантазии нужно много, не спорю :). Другое дело, что набора фильтров тут действительно пока нету. То есть я их уже написал немало, но с использованием других моих классов, причем так, что тупо выдирать их смысла нету. Возможно в ближайшее время у меня дойдут руки и я перепишу фильтры, а пока, кому интересно, могут просто побаловаться с самим классом.
Тем более, тут интересна сама идея. Хороший программист поняв идею сам за день-два напишет все необходимые фильтры. Хотя ввести какой-нибудь стандарт было бы действительно полезно. Тем более, что он мною уже почти доработан. Постараюсь всё доделать)
правда, класс такой метод не съел, пришлось его дописать. со следующего коммита на GitHub'е эта запись станет корректной и будет работать.
осталось только по тестам прогнать.
1) в разы сложнее.
2) нету такой гибкости -> область применения много меньше.
3) завязано на классах… точнее увязано в классы.
4) сложнее интегрируется. (если не родной фреймворк)
5) неоправданно много внутренней логики.
Не вижу смысла тянуть за собой таких гигантов, когда нужно лишь проверить данные или преобразовать их в нужную структуру.
И да… вы кажется тоже не прочитали статью. Я предлагаю метод близкий к нативному, но при этом очень функциональный.
Я понял вашу идею, но вы привели слишком плохой «пример». Действительно, такую операцию можно запихнуть в функцию. Поэтому я усложню задачу. Допустим, помимо вашего условия, нам нужно проверить исходные данные (или привести их к integer). Такой алгоритм будет выглядить так:
Strain::add('must_be', function($value, $options) {
if (Strain::it($value, $options)) return true;
});
Strain::add('triangle', function($value, $options = null) {
if ($value->a+$value->b c || $value->a+$value->c b || $value->b+$value->c a) return true;
});
Да, довольно непонятно написал. Я уже, если вы заметили, поправил название на 'must_be_integer' чтобы никого не вводить в заблуждение. TRUE — говорит нам о наличии ошибки.
Тут можно поспорить о том, как лучше. Ваш вариант более интуитивный, мой — более логичный, потому что при фильтрации объектов удобнее анализировать Strain::$result конструкцией if, например if($result->name), ведь там может быть и TRUE и строка содержащая информацию об ошибке. В вашем случае нужно будет писать if($result->name !== true).
Это единственная причина такой путаницы.
Если вас это уж совсем смущает, то отредактируйте метод it(), чтобы возвращал наоборот. Там всё предельно просто.
Тем более, тут интересна сама идея. Хороший программист поняв идею сам за день-два напишет все необходимые фильтры. Хотя ввести какой-нибудь стандарт было бы действительно полезно. Тем более, что он мною уже почти доработан. Постараюсь всё доделать)
Лицензия скорее всего будет введена с версией 1 и то исключительно на набор функций, но никак не на сам класс.
$value = (object) array(
'a' => 2,
'b' => 3,
'c' => 4
);
$valid = array((object) array(
'a' => 'integer',
'b' => 'integer',
'c' => 'integer'
), function($value, $options = null) {
if ($value->a+$value->b <= $value->c || $value->a+$value->c <= $value->b || $value->b+$value->c <= $value->a) return true;
});
var_dump(Strain::it($value, $valid));
правда, класс такой метод не съел, пришлось его дописать. со следующего коммита на GitHub'е эта запись станет корректной и будет работать.
осталось только по тестам прогнать.
2) нету такой гибкости -> область применения много меньше.
3) завязано на классах… точнее увязано в классы.
4) сложнее интегрируется. (если не родной фреймворк)
5) неоправданно много внутренней логики.
Не вижу смысла тянуть за собой таких гигантов, когда нужно лишь проверить данные или преобразовать их в нужную структуру.
И да… вы кажется тоже не прочитали статью. Я предлагаю метод близкий к нативному, но при этом очень функциональный.
$value = (object) array(
'a' => 2,
'b' => 3,
'c' => 5
);
Strain::add('must_be', function($value, $options) {
if (Strain::it($value, $options)) return true;
});
Strain::add('triangle', function($value, $options = null) {
if ($value->a+$value->b c || $value->a+$value->c b || $value->b+$value->c a) return true;
});
$valid = array('must_be' => (object) array(
'a' => 'integer',
'b' => 'integer',
'c' => 'integer'
), 'triangle');
var_dump(Strain::it($value, $valid)); // (TRUE — если ошибка, FALSE — если всё ок)
*протестировано
Тут можно поспорить о том, как лучше. Ваш вариант более интуитивный, мой — более логичный, потому что при фильтрации объектов удобнее анализировать Strain::$result конструкцией if, например if($result->name), ведь там может быть и TRUE и строка содержащая информацию об ошибке. В вашем случае нужно будет писать if($result->name !== true).
Это единственная причина такой путаницы.
Если вас это уж совсем смущает, то отредактируйте метод it(), чтобы возвращал наоборот. Там всё предельно просто.
К тому же, это не просто валидатор. Возможность привести непонятные данные к строгой структуре может быть востребована где угодно в разработке.