feat: allow overriding the validation process

[SychO9]

Hello 👋🏼,

In our use case we wish to validate all the fields together to enable certain validation capabilities in illuminate/validation (such as required_with). But also, we want to entirely rely on illuminate/validation.

Opening up the assertDataValid for overriding would allow for this to be possible.

[tobyzerner]

I'm wary of opening up the private methods of the SavesData trait at this stage, since the way they're structured feels somewhat arbitrary (like an implementation detail) and opening them up would mean any refactoring in the future would require a major version bump. It's still something I need to think about in more depth.

In the meantime what about these options?

• If I added the $data array to the Context object, could you write a custom rules helper which passes in all of the data to the validator for each field, so that cross-field rules like required_with will work?
• Or, could you subclass Attribute to add your rules methods, and then perform validation in the Resource class's create and update methods?

What do you think?

[SychO9]

Totally understandable!

could you write a custom rules helper which passes in all of the data to the validator for each field, so that cross-field rules like required_with will work?

helper might be limiting compared to the API we ended up with, but will see.

Or, could you subclass Attribute to add your rules methods, and then perform validation in the Resource class's create and update methods?

would move validation after field setters i believe, which is too strong a change.

However, we can always just rely on custom Create/Update endpoints instead (that's how it was implemented prior to the fork) so that's not a blocker.