views.generic.edit.FormMixin should have a get_context_data() method

[andrei kulakov]

Currently SingleObjectMixin and MultipleObjectMixin have get_context_data but FormMixin does not, instead form is added to context via an argument in get() method.

The reason for this is probably because it's just one line of code and it did not seem to warrant a method.

However, it would be really nice to have this method for a few reasons:

1. consistency: FormView, UpdateView, CreateView context gets populated in the same way as in DetailView and ListView. When GCBVs are customized, users will know that context is populated in the same place for all views.

2. From the point of view of documentation, it's also easier because you can tell users where context is created for all views rather than specifying two different places, especially because you have to explain that argument to get_context_data gets added to context.

3. Logically, it seems like it should belong to get_context_data(). A user who is not closely familiar with GCBVs may be confused as to where context comes from in Form Views. get_context_data() is an unambiguous location for this logic as indicated by the name.

4. It makes it easier to combine different GCBVs. In case of FormView and CreateView, you don't need to do anything in get() method (in CreateView you may simply init self.object=None at class level), therefore when combining these views with others, you can simply use get() methods from the other View and let get_context_data() handle contexts of all inherited views.

There are two alternatives: form initialization may be removed from get() and post() methods OR it may be left there along with duplicate logic in get_context_data(). In the former case it may be a backwards-incompatible change - although get_context_data() is supposed to include a super() call to parent get_context_data() methods, users may have it without the super() call -- thus form will disappear from context.

If form init is left in get()/post(), it's probably an acceptable performance cost. Perhaps it can be left in but deprecated.

PR 4512