On Mon, Apr 6, 2009 at 3:09 AM, Dan Tallis <[email protected]> wrote:
> > It's not clear to me from the thread so far whether there has been a > decision to back out 10206 There hasn't been a decision. I'm still thinking about it. > but, to add some more evidence, I would > point out that it has also made it rather more awkward to process > formsets: You can no longer iterate over form.formsets (e.g. in a save > method) and consider cleaned_data, since it might not be present. > Unless I've missed something, there's deleted_forms, but no analogous > non_deleted_forms (which would help, but may still require quite a lot > of applications to change their approach). It was never possible to iterate over every form and blindly check form.cleaned_data because it has never existed for invalid forms. The only difference is that you can no longer expect cleaned_data to exist for every form if formset.is_valid() returns True. You can still iterate over every form, check form.is_valid(), and decide not to check form.cleaned_data there. The change hasn't deleted form errors, they just don't prevent the entire formset from being valid anymore. > Also the documentation [1] includes code that will no longer work in > general: > > >>> [form.cleaned_data for form in formset.deleted_forms] > > (may fail because form.cleaned_data will not be present if the form > had 'delete' set but other field-level validation errors). > Ah. I'll need to change that at some point. Thank you for pointing it out. > Thinking about possible ways forward, one observation that occurs to > me is that I think there's a significant semantic distinction between > field validation and form-level (non-field) validation that applies in > this case: Field validation errors on forms with delete should not > cause formset is_valid to return False but perhaps form-level errors > should...? > Ugh. Please no. This is the kind of subtlety that has been so terrible to deal with in other languages. What Malcolm said still applies. Deleted data is not data. Form validation is the wrong place to veto deletion. It is an entirely separate thing. The only reason I'm considering rolling this back instead of adding hook for deletion is because there likely won't be another beta release, and we're very close to releasing 1.1. The fix probably deserves a little more time and eyeballs than it would get. Rolling back is just delaying the 3 lines of code you'll probably have to add once there's a proper way to veto deletion. I'll post to this thread if and when I decide to roll back the change. It's spread across at least 4 different commits on different days. Rolling it back is more than a 5 minute job. Joseph --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
