Laravel 4.3 Form Request Validation

Yes, that should work, I believe. Because the rules() method is called, using the new App::call(), you can leverage method injection.

It's not an approach I would choose, but it's up to you.

I don't see any reason why it wouldn't work.

However, wouldn't the rules vary from form to form? For instance, when a user wants to update their profile, checking that the username or email is unique would be counter productive...

The goal with Request is to validate the request itself, not the model. If you want to keep rules with the model, you can use static $rules, and then return MySuperModel::$rules.

Thanks, @salebab. That perspective makes sense. I have found that most often I am validating my models. Right now I am using watson/validating, and it has provisions for creating, updating, saving, and custom events. I plan on making a trait that will allow for multiple rules and rulesets, something like:

protected $rules = [
    'name' => 'required', //default rule
    'username' => 'required|unique:user:username', //default rule
    'updating' => [
        'name' => 'required',
        'bio' => 'max:55',
    ],
];

and so forth. Then, if I have a form that is tied to multiple models, I could import the rules for all the models. Here's why I think it makes more sense to keep the validation rules with the model, than in the FormRequest object: - models need to be validated before accessing the database to make sure they conform to the database representation of themselves (field requirements in tables, etc.) - form data will 99% of the time be saved off to a database, so it will more than likely end up being part of a model, which is essentially an abstraction of a database record - those items that are not being persisted in the database should have their validation in the the rules method of the FormRequest object, that makes complete sense - by injecting the models or referring to the static variable, I can then combine them as needed in the FormRequest object to suit the form.

Thanks for all your input, everyone :)

I agree with salebab's perspective, I don't think the model should be responsible for validation as that seems like it'd be breaking the single responsibility principal. In that respect, the rules are specific to the validation process.

Given my previous example, the model doesn't change but the rules required to validate do. Therefore, I'd keep the rules with the validation request.

Actually I don't see your point on validation in the model, @mikebronner. You said, that models need to be validated. So first of all, you said, that they are validated by another object, because the model needs to be validated, i.e. it's not doing it itself. You gave yourself the proof, why this does not belong into the model :) You are mixing the concerns here in my opinion. Secondly you are strictly tying your input forms and everything around it to your model instead of designing these according to the client's specification. Otherwise you would have to validate your data twice: Once to validate a correct input format in your form (or however you get your data) and then to validate the data format provided to the model. Why double the work? Finally in the inner borders of your application you as a developer are responsible for maintaining the integrity of your data by the code you write. Only user input (i.e. data from the outside of the system) has to be validated to meet the requirements of our application as we all have learned. By pushing the validation back to the point where it is inserted into the model, you carry potential data inconsistency a long way into your application. Imagine a night club where the doorman is not protecting the entrance to the club but the entrance to the dance floor. There would be chaos around the dance floor :)

Thanks @DavidB and @Devon for sharing your insights. I do agree that validation should be placed as early as possible to the data entry point in the application. However, I see validation rules as type definitions of a model. Or like field definitions on a table. They specify what shape the data needs to take to be acceptable for saving to the data store. That aspect I like to keep as close to the model as possible.

I wouldn't be validating twice, just once. Also, when I develop the model I am also considering the data type requirements, which are the validation rules. Why would I want to think about that later in the game.

I do see your points you are making though, not trying to argue they aren't valid. :) Please feel free to counter anything I'm saying here, its a good discussion.

I guess the bottom line is that I will have to try it out and see how it works before making up my mind. :) In the end I did get the answer I was looking for, I'll see if it makes sense at all after 4.3 comes out.