Validator ideas about django-adapters HOT 7 OPEN

Custom error handling isn't so necessary there now we have add_error. This does lead to the idea that a ValidationError could just be bound to two fields and displayed however the renderer wants. That said, sometimes although the validation crosses fields, the error is explicitly about one of the fields.

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.

from django-adapters.

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 Validator that only overrides validate is a candidate for a frontend mirror, whereas one that overrides clean is not.

Perhaps some data transformations can considered cheap and idempotent, like int(value), so maybe they can be mirrored too. But this would require that they don't break earlier validators too, so this is a lot more complex to allow.

from django-adapters.

The problem is, if a "plain" validator depends on a cleaning one, then you need to mirror them all.

from django-adapters.

Yeah... it's probably impossible to handle in the generic case. That shouldn't stop us thinking about how to support a subset though.

from django-adapters.

One really shiny thing that a tree/dag of validators/cleaners allows is a ValidationError will only prevent dependent validators from running. This is much nicer than the current case where a Form.clean method only runs if all other validators pass. This is nicer than checking manually in Form.clean which fields have been successfully cleaned and which have failed validation.

from django-adapters.

I think my crossed-out comment does apply to a DRF Serializer.validate method.

The structure also allows raising more than one cross-field ValidationError without needing custom error handling within the Form.clean or Serializer.validate method.

from django-adapters.

As I already mentioned in #27, I really dislike how accessing form.errors in Django currently triggers a full validation (or clean).

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 clean() or not.

from django-adapters.