Меню
Что нового?

Laravel А что greater than нету?

Vano

Новичок
Нету валидации greater than? Как тогда организовать валидацию больше от 0, ну или просто положительное число?
 

Vano

Новичок
Ладно поставил min:0.01 так как валидировать нужно цену, меньше чем одну копейку вряд-ли будет цена. Но блиин... Ларка...
 

Vano

Новичок
Ладно еще один вариант
Код: 
'price' => ['numeric', 'min:0', 'not_in:0'],
Но блиииин, почему нету not equals простого?
 
Adelf

Adelf

Administrator
Команда форума
Потому что это валидация формы. А твой случай - это бизнес-валидация. Оно должно быть проверено вручную. Вне всякого HTTP, HTML и других веб-сущностей. И если цена 0 или меньше - должно быть выброшено исключение - IncorrectSumException или что-то в этом роде. А потом уже превращено в нормальный текст ошибки для пользвателя. Но это если у тебя приложение конечно... не "Hello, world"

Я не оправдываю ларку. валидация у нее хромает. все эти unique и exists...
 

Vano

Новичок
Хммм. Так валидировать, всё таки, нужно только на принадлежность к спектру того, что можно ввести в ШТМЛ? То-есть никаких Unique, exists, и даже MIN для числа?

Можете пожалуйста поподробнее обьяснить?
И другой вопрос можно ли в Requst (валидаторе ларавела) произовдить так называемый "sanitize".( http://www.easylaravelbook.com/blog/2015/03/31/sanitizing-input-using-laravel-5-form-requests/ ). Я догадываюсь, что это неправильно.
 

Vano

Новичок
И уже тем более в Request'е нельзя переделывать - допустим есть оптионбокс, у них значение ["not_exists", "exists"], переделывать в 1 или 0, потому что так в БД записывается. Я прав?
 
Adelf

Adelf

Administrator
Команда форума
Почему - это долго обьяснять. если кратко, то валидация не должна знать где и как хранятся реальные данные.

Про sanitize - я не думаю что это так уж плохо. В данном случае Request очищает HTML форму... и передает данные в нужном для остального приложения формате. Но мне не нравится как сделано в той ссылке которую ты прислал. Нельзя портить исходные данные. Например, мои реквесты выглядят так:

PHP: 
class LinkCreateFormRequest extends Request {

    public function authorize()
    {
        return true;
    }

    public function rules()
    {
        return [.... тут правила....
        ];
    }

    /**
    * @returns string
    */
    public function getTitle()
    {
        return $this->get('title');
    }


    /**
    * @returns Carbon
    */
    public function getStartDate()
    {
        return Carbon::createFromFormat.... $this->get('start_date'); - не помню как..
    }


    /**
    * @returns bool
    */
    public function isFinished()
    {
        return $this->has('finished');
    }
}
 
  • Like
Реакции: Vano

Vano

Новичок
@Adelf, Спасибо, по крайней мере isFinished() это для меня решение одной задачи) Если я правильно понял, то методы get у тебя это уже готовые данные для (например) записи в БД. А данные из формы, ты оставляешь без изменений, авось иногда понадобится данные которые ввел пользователь.
 
Adelf

Adelf

Administrator
Команда форума
Чаще всего да. Если у тебя обычное CRUD приложение.
А так.. это просто данные, которые удобно дальше обрабатывать. Откуда они пришли - из HTML формы или из мобильного приложения - не так важно для того кода, который будет эти данные обрабатывать.

Vano написал(а):
@fixxxer, пинг. Так почему не нужны?
Нажмите для раскрытия...
я тебе ответил кратко уже.
 

Vano

Новичок
@Adelf,
я тебе ответил кратко уже.
Нажмите для раскрытия...
Ну, то-есть, на этом этапе (этапе валидации данных которые пришли от пользователя, которая происходит, так сказать, перед! выполнением Экшна) валидировать правильно только спектр того, что по-идее должен прислать юзер. А уже когда контроллер выполняется можно производить/выполнять/ или как сказать, бизнесс-логику. А is...() метод я уже нашел применение не для записи в БД) - isRemember() допустим.
 
Adelf

Adelf

Administrator
Команда форума
Я тебе один умный вещь скажу, но только ты не обижайся. Не надо в контроллере бизнес-логику делать. Контроллер - из самого названия понятно, должен контролировать только. Выполнение HTTP-запроса. Бизнес-логику должен делать отдельный слой бизнес-логики. Который ничего знать не должен про HTTP, HTML и т.д.
Но вероятно, тебе еще рано так делать. Должен сам к этому прийти.

P.S. А так, да. ты прав. валидация должна только в своем спектре обязанностей. просто провалидировать, что юзер правильно заполнил форму.
 
Последнее редактирование:

Vano

Новичок
@Adelf, АААай!!11 Я не написал что в контроллере будет делатся бизнесс-логика) Имею ввиду что контроллер должен получить достоверный риквест (тот который ввел пользователь)
Раз уж он должен обрабатывать риквест.
 

Вурдалак

Продвинутый новичок
fixxxer написал(а):
layering violation потому что
Нажмите для раскрытия...
На это можно взглянуть с другой стороны.

Если же форма обращается к query services, то это ничем по сути не отличается от классического кейса с проверкой доступности логина сразу после его ввода.
Это опциональная проверка, которая нужна лишь для удобства.
Она не исключает проверки при вставке, если угодно, но тем не менее, я в ней не вижу ничего особо криминального.
 
fixxxer

fixxxer

К.О.
Партнер клуба
Так-то да, меня скорее смущает реализация, гвоздями прибитая к eloquent.
 
  • Like
Реакции: Vano
Войдите или зарегистрируйтесь для ответа.
Сверху