Add rules() function to Validation trait

[goldmont]

Hi,

In certain situations Validator rules needs to be computed dynamically. As of now, I have to declare the $rules property as an empty array and then, in the model constructor, I have to update its value with my desired rules.

E.g.
I use to check if a certain value is compatible with the enum MyEnum. In order to do so, I have to create an array of cases on the fly. However, PHP doesn't allow you to do that outside of a function.

public $rules = [];

public function __construct(array $attributes = [])
{
	parent::__construct($attributes);
	$this->rules = [
		'title' => 'required|string|max:191',
		'status' => TaskStatus::casesAsValidatorRule(),
		'deadline' => 'nullable|date',
	];
}

It would be nice to have a rules(): array function that allows us to simply return an array of rules dynamically computed. Just like Laravel does here.

Then, this condition inside Validation trait will be:

if (!property_exists(get_called_class(), 'rules') && !method_exists(get_called_class(), 'rules')) {
    throw new Exception(sprintf(
        'You must define a $rules property or a rules() function in %s to use the Validation trait.',
        get_called_class()
    ));
}

Also, $rules property and rules() function must be mutually exclusive.

[mjauvin]

@goldmont You could use the model.beforeValidate event to dynamically set your rules.

[goldmont]

@goldmont You could use the model.beforeValidate event to dynamically set your rules.

Sure, I know that too but I prefer to not split the rules. I think that's clearer to have all of them in the same place. What do you think about?

[goldmont]

Think about rules() function like an alternative way to populate the $rules property leaving the whole Model lifecycle untouched.

[mjauvin]

@bennothommo would that fit in your PR to add Laravel style relations?

[bennothommo]

This would be separate to the Laravel relations PR.

I'm definitely not adverse to adding support for a rules() method as @goldmont suggested to the Validation trait, as long as it's on top of of the current functionality of defining it in the property, not instead of.

[LukeTowers]

In theory this should be easy enough to implement by adding the rules() method in the Validation trait and just having it return the rules property by default; however I would be concerned about potential naming conflicts with existing code if we just called it rules() (i.e. someone could very easily have existing relationships etc called rules() that would conflict), so we might have to call it validationRules() instead.

[goldmont]

@LukeTowers Could this conflict happen also with the $rules property or am I wrong? Think about $model->rules

[bennothommo]

@LukeTowers I agree with @goldmont - I don't think there would be much likelihood of people using the rules() method as a relation because - a) using rules() as a relation would imply a Laravel-style relation which only half-work in Winter and b) it would conflict with the Validation trait now - the property rules would go to the validation rules property and not the relation.

EDIT: As to people using rules() for another purpose - we can minimise the potential clash by checking if the method returns an array before considering it the source of truth for validation rules, falling back to the $rules property if it doesn't.

[LukeTowers]

Fair enough, I'm fine with that.