CodeIgniter Forums
More flexible validationRules in model? - Printable Version

+- CodeIgniter Forums (https://forum.codeigniter.com)
+-- Forum: CodeIgniter 4 (https://forum.codeigniter.com/forumdisplay.php?fid=28)
+--- Forum: CodeIgniter 4 Feature Requests (https://forum.codeigniter.com/forumdisplay.php?fid=29)
+--- Thread: More flexible validationRules in model? (/showthread.php?tid=75620)



More flexible validationRules in model? - michalsn - 02-26-2020

Is there any reason why we don't support methods like setValidationRules/setValidationRule in our Model class? I think it would be very convenient to have them. The same thing with getting and setting $allowedFields variable array - we can't do it now outside the model.

Very ofter validation rules and allowed fields for inserting and updating data are different.

I know that if I want to change some validation rules I can get them in the controller (via $model->getValidationRules()), change and make validation there. But what with a scenario where I don't use controller but just a class? Making a special method for validation in every class or just creating some common class to share functionality doesn't sound like an optimal way to do it for me.

It would be much easier to just call getValidationRules, make changes and then use setValidationRules to set them back.

The other way to go would be to have separated validation rules for insert and update, but it wouldn't be so flexible like letting to set rules dynamically.

I would be happy to make a pull request.

Any thoughts? Pros/cons?


RE: More flexible validationRules in model? - zahhar - 02-27-2020

This is a very valid architecture point, michalsn.

I would fully support getters/setters for (almost) all protected attributes, like $validationRules or $allowedFields. Moreover, it is very easy to implement and suggest to include into subsequent releases of CI4.

When it comes to separation of validation logic and and list of allowed fields for create/update actions, I like the approach RubyOnRails uses in its ActiveRecord:

1. You can define generic validation rules applicable in any case, and on top of that customize them for create/update actions. Totally makes sense: https://guides.rubyonrails.org/active_record_validations.html#on

2. For $allowedFields differenciation on updated/create it offers slightly different approach: Model is allowed to have readonly attributes. Those attributes will be set only when record is created using $myModel->insert(), but ignored during $myModel->update() call. It would be cool to have $readonlyFields introduced in CI4.x.

I am also happy to work on pull request.


RE: More flexible validationRules in model? - MGatner - 03-01-2020

Seems like there are two threads here: situational model validation rules (like create vs update) and external access to the rules. I love the first, though it seems easier to imagine than implement cleanly. The second idea I'm not opposed to but it makes me ask "why"? A model is already a set definition of data and methods to access that data, it seems odd to want to make that dynamic. If you need a different set of rules, I would just make a different model (could still use the same table). If the validation needs to be that dynamic and accessed from other classes, etc, why not make it its own validator? (Like Myth:Auth, which I know @michalsn has worked on)
Those are all real questions, my mind is definitely open on this one!


RE: More flexible validationRules in model? - michalsn - 03-02-2020

The thing is that introducing separated valuation rules for insert and update would be a BC change and would have to wait until v4.1 release. That's the only downside.

When it comes to dynamic rules changing - from my point of view, it would be simpler than creating a separate model just to have different validation rules. Also, validation rules may differ for example by user permission/group... but as you said - validation can be done also outside of the model. Although it would mean that you always have to write more code... but now I'm thinking... maybe it's actually the right approach that everyone should use?