I hate that if validation fails the flow of my app is controlled thought the FormRequest Class instead of my controller. Am i alone here?
if i add this to my formRequest i think i can bring control of the failed validation back to my controller! (not tested!)
public isValid = true;
public errors;
public function response(array $errors)
{
$this->errors = $errors;
$this->isValid = false;
}
public function forbiddenResponse()
{
$this->validation_errors = 'Forbidden';
$this->isValid = false;
}
then in my controller i can easily do
public function store(CreateTaskRequest $request)
{
if (!$request->isValid) {
// handle failed validation here
}
return view(‘tasks.list’);
}
I can definitely see your point. It might be taking one too many responsibilities away from the controller and FormRequest is a slightly misleading name if it's handling responses too.
But the idea and implementation is hugely convenient and injecting the class into the controller method makes it pretty clear that something semi-magical is happening there.
What might be cool is a boolean autoValidate field in the FormRequest class. I haven't had a good look at the code yet so I don't know how it all works, but I'm sure a bit of extension might make that possible.
I definitely agree with you, unitedworx. I also don't like how the FormRequest's "catchall" validation method for custom validation rules is called authorize(). If I'm doing something like testing to make sure a zipcode is a valid zipcode for a state, that has nothing to do with authorization - it's just an extra validation check. While I could write my own validation rule and reference the rules array, sometimes it's a bit unnecessary to write a separate validation rule for a one-off comparison.
I'd almost agree with you, but here's a scenario as to why you might not want to have the logic in the controller.
Imagine that you have a single FormRequest class that is used multiple times. By having to put your response logic in each controller method, you are very likely duplicating code. Most of the time, you probably only want it to go back to the previous page, and display errors.
On the off chance that you want to have specific functionality for each instance, then you have to have unique FormRequest classes for each controller method. Basically, this allows the majority to not have to duplicate code.
I have watched the video, though I have not yet tried using those FormRequests. I feel like those FormRequest might be useful to validate simple things, like a required field, a confirmation field, or anything tied to the form itself.
For more complex validation, I would prefer using a command validator, which would be part of my domain.
I won't argue that it removes a lot of duplicated code and makes things simpler, however this takes away from the controller how a failed response is handled.
I am handling most things in my admin area with Ajax requests and need more control on how a failed response is sent back.
You don't lose any of the control. The difference is that if you want to override the default response, you need to override the response method in the FormRequest.
I have the same concern with letting the FormRequest class handle responses.
You can actually do a lot of the FormRequest's resposne magic this with the base controller class already, and it's surprisingly convenient. The controller has a callAction() method that actually executes the route-function mapping, so you can extend that function in your base controller class and wrap it with the same boilerplate that you find in the FormRequest response functions.
I have nothing against what everybody as said here, but I think it's an awesome idea, saves lots of boilerplate and I will sure be using it, in fact thinking of rebuilding my invoicing system I built with 4.0 to 4.3 this weekend.
This way I get to play around with it and see all it's new features and new ways to do everything. Laravel is really going places and thanks to @JeffreyWay, Taylor and the rest of the community it's getter better and easier to use and maintain.
What I've been doing, even with the Command approach in 4.2, is throwing an exception which I then catch in my controller. That way, I can allow the controller to remain in control of what happens while the Command (or, in this case, Request) can do what it needs to do to validate, update, save, or delete... It's not the most elegant approach, but it allows me to control my app from a single location instead of trying to find out who/what issued a redirect.
I was watching the video of Mathias Verraes' talk at Laracon EU 2014 and his analogy really puts it into perspective... He compares it to a war where the King might give a command to a unit to attack and then they'll send a message back saying that they've either won or lost. What doesn't happen, however, is that the unit doesn't automatically redirect to another battlefield after a win and certainly not after a loss; instead, they retreat and await their next command.
