On Mon, May 6, 2013 at 12:46 AM, Aymeric Augustin < [email protected]> wrote:
> Hi Luke, > > I'm also skeptical about validation when: > - it tries to analyze statically dynamic behaviors; > - it fails on code that actually works. > > To me it looks like the admin outgrew its own validation, and > as a consequence the validation needs to be re-engineered. > > Christopher Medrela applied for a GSoC on validation. While > his proposal doesn't address this specific problem, I think it > would make it easier to resolve. > I don't think this is entirely true. Christophers' work will provide some nicer hooks for validation, which means we'll allow end users to write their own validation for their own field types etc, and won't need to have one great big "VALIDATE" method anymore. That might result in some refactoring of the Admin's validation code, but I'm not sure actually improving the Admin validation itself is on the project schedule. Overall, when it comes to correctness vs. convenience, I sit > on the side of correctness :) so count me as +1 if you're > changing validation to stop assuming static behavior that > isn't guaranteed. > No disagreement here. Validation is supposed to be a helper to avoid common errors; if we can't do that reliably, we shouldn't be doing it at all. In this case, I suspect Luke is correct in saying that the better approach is better runtime error messages when a configuration won't work. As for the "ModelForm without a Meta" approach -- I see what you're driving at, and I can see how it's an elegant solution to the problem. My concern is that we'd be encouraging people to pass around "half-baked" ModelForm definitions -- i.e., under any other circumstances, a ModelForm without a Meta wouldn't be valid. If someone puts that ModelForm into a forms.py, it's going to appear like it can be used as a form in general usage… except it can't. The only alternative that immediately comes to mind is allowing a flag to be passed into the constructor for a form that explicitly allows "insecure default all-fields" behaviour. The admin would always pass in that flag, users could if they wanted to (but at least they'd be opting in to a known potentially insecure behaviour). I'm not saying I particularly like this option either; I'm just floating it as an alternative. Russ %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
