Closed SychO9 closed 3 months ago
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?
$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?Attribute
to add your rules methods, and then perform validation in the Resource
class's create
and update
methods?What do you think?
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.
Hello 👋🏼,
In our use case we wish to validate all the fields together to enable certain validation capabilities in
illuminate/validation
(such asrequired_with
). But also, we want to entirely rely onilluminate/validation
.Opening up the
assertDataValid
for overriding would allow for this to be possible.