This is an old thread, but we never came to a conclusion. I'll respond to Anssi below, and then add my own ideas.
> I find the option of raising warnings or errors on missing data > elements the best option forward. There is one unfortunate downside, > that is we can't do this for checkboxes. So, it would be possible to > have a hidden-editable checkbox field. I don't think this is a great solution at this point. The hidden-editable checkbox field is going to be backwards incompatible in a serious way, because many forms are rendered manually in HTML, and they will break. I'm not convinced that warnings are ever a useful security mechanism, because they are so easily ignored. In production, they are invisible by default, and in development they are only visible if you look at the devserver output. Further, when a warning is correct, it shouldn't be a warning, it should be an error. When the warning is in fact incorrect, then it is a nuisance, and can easily lead to people ignoring or silencing all warnings, unless we also provide an easy and very fine grained way to deal with them. Warnings that are only sometimes correct always do the wrong thing. This contrasts with deprecation warnings, for example, which are always correct - because the functionality is indeed going to go away, and you do need to do something about it, but it isn't an error because the code is working OK now. The presence of the warning encourages you to do the right thing to get rid of it - migrate your code. My idea: I think, given the lack of consensus in this thread, that we have to opt for a conservative option. I like Alex Ogier's solution of a sentinel "__all__" flag. This would be introduced for ModelForm and UpdateView using a deprecation process, so that a form without one of 'fields' or 'exclude' will raise a PendingDeprecation warning initially, and eventually be illegal. Both the '__all__' shortcut and the use of 'exclude' will be plastered with warnings in the docs, and the docs will be re-written to assume that you are going to provide 'fields' (at the moment the opposite is assumed). How does that sound? Luke -- "If you're not part of the solution, you're part of the precipitate." (Steven Wright) Luke Plant || http://lukeplant.me.uk/ -- 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.
