New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Validator ideas #10
Comments
I like this. A clear distinction between validation and cleaning may also be useful for distinguishing validation that can only happen on the backend and validation that may also run on the frontend. In your structure above, it seems to me that any Perhaps some data transformations can considered cheap and idempotent, like |
The problem is, if a "plain" validator depends on a cleaning one, then you need to mirror them all. |
Yeah... it's probably impossible to handle in the generic case. That shouldn't stop us thinking about how to support a subset though. |
One really shiny thing that a tree/dag of validators/cleaners allows is a |
I think my crossed-out comment does apply to a DRF The structure also allows raising more than one cross-field |
Custom error handling isn't so necessary there now we have Another edge case I've just thought of which I'm not sure how well it fits, and definitely isn't clearly mirrorable, is validation which depends on a hidden aspect of the bound intial object(s). It would seem a bit clunky to require constructing the serializer using the instance we are going to operate on AND then having to pass it to the initial step. It kinda opens up a question about read/write patterns - if we have a read only field which is marked as hidden for renderers then we can cross field validate using it later. The balance between read/write different behaviour on the same object and having distinct objects for read/write is an interesting one. |
As I already mentioned in #27, I really dislike how accessing I agree that separating cleaners and validators makes sense but I think it would be ok to have them both subclass from the same base class and dynamically detect if they overrode |
Not 100% sure about the split between
clean
andvalidate
but there is a difference between the two. Perhaps instead we havecleaners
andvalidators
, one of which changes and one of which doesn't, but they're chainable together.Related but not necessarily belonging in this tree is idea of a
shaper
which is a multivalued cleaner which returns different data shape. Then again perhaps these should be in the validator tree so subsequent validators can use the changed shape. Shaping is also about input/output though so these lines are blurry.The text was updated successfully, but these errors were encountered: