Bill de hÓra wrote: > Gary Wilson wrote: > > What do you think about adding a ValidationError similar to > > CriticalValidationError but one that would stop further evaluation of > > _all_ validators in the manipulator instead of just the remaining > > validators for the current form field being processed? > > It's not an error, it's a directive to the engine to stop downstream work: > > raise StopValidating
Well, it's both. > Personally I don't like it when installed components have the ability to > blow up the containing code /by design/. There's that. There's also > introduction co-concurrence constraints in validators, where validators > depend on other validators being ahead of them to for gigo reasons and > validators are designed to blow up because they 'know' downstream > components are going to be fragile or not doing useful work - imo it > lowers overall robustness. I'd argue the validators teed up this way > aren't cohesive and should be coupled together - either use a strategy > pattern, or nested pipelines*. > > cheers > Bill > > * the validation engine loads one validator, but it's made up of one or > more valdiations which natually belong together and can be locally > optimised. I'm not sure I understand exactly what you mean about blowing up the containing code. The error would be caught in the manipulator's get_validation_errors() method like the other ValidationErrors. I agree with your concurrence statements, order of formfields would become a factor just as ordering of a formfield's validators is important for the CriticalValidationError. hasCookiesEnabled doesn't need to know what's downstream, it wouldn't care. If hasCookiesEnabled validator doesn't pass, the user can't login regardless of what other formfields need validating. You could put the hasCookiesEnabled and isValidPasswordForUser validators together, but I wouln't say that they natually belong together. Maybe the problem is that the hasCookiesEnabled validator isn't really tied to a formfield, but rather is more of a manipulator-level validator. Currently, validators must be coupled to a form field, so that's where the hasCookiesEnabled validator must go. Maybe we could have manipulator-level validators that, if fail, short circuit the evaluating of formfield-level validators. I don't know where the error message would go in the error dict however. Maybe under a "manipulator" key. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~----------~----~----~----~------~----~------~--~---
