Validation Decorator about commander

[salebab]

I've found the best approach for me is to keep validation rules within a command (like rules in form requests in Laravel 4.3). To do that you need to use a custom translator and to define a validator class, e.g.:

class CommandTranslator extends BasicCommandTranslator {

    public function toValidator($command)
    {
        return 'Acme\Commander\CommandValidator';
    }
}

And your CommandValidator might look like:

class CommandValidator
{
    /**
     * Validate a command
     *
     * @param Command $command
     * @return bool
     * @throws \Acme\Exceptions\ValidationException
     */
    public function validate($command)
    {
        if(method_exists($command, 'rules')) {

            $rules = $command->rules();

            if(!empty($rules)) {
                $validator = \Validator::make((array) $command, $rules);

                if($validator->fails()) {
                    throw new ValidationException($validator->getMessageBag());
                }
            }
        }

        return true;
    }
}

Now, you do not need to create a validation class for each command, just put:

public function rules() 
{
    return []; // define your rules here
}

Hope this helps :)

P.S. Don't forget to bind a custom translator. You can drop it to your global.php, e.g:

App::bind('Laracasts\Commander\CommandTranslator', 'Acme\Commander\CommandTranslator');

[JeffreyWay]

Validation has now been ripped out for Laravel 5.

[keithmifsud]

Hi Jeffrey,

shouldn't the command have it's own validation separate from the form validation and the domain/model validation?

At the moment using L4 I use:

a) form validator which returns user friendly messages and who's sole interest is the user input. I call this from the controller before executing the commands because the transport ios directly related to the view.

b) I have a command validator whos purpose is to validate the data passed to the command. In my opinion this is generally different from the form as a form can have recaptcha and other user verification methods. The command is not interested on what data was inputted or displayed to the suer but only to handle the command (not the form or the database).

c) The model itself will have it's own specification services. Different from actual input validation as this valudated objects with their types and properties normally using typecasting.

d) Most infrastructure services will have their own rules and validators such as the ORM, API services etc etc...

I understand otehr may think of this as duplication but it really isn't as all these layers have seperate concerns and to be fair perform different unrelated processes.

I'd appreciate your thoughts on this if you get a chance :)