#24643: views.generic.edit.FormMixin should have a get_context_data() method
-------------------------------------+-------------------------------------
     Reporter:  akulakov             |                    Owner:  akulakov
         Type:                       |                   Status:  new
  Cleanup/optimization               |
    Component:  Generic views        |                  Version:  master
     Severity:  Normal               |               Resolution:
     Keywords:                       |             Triage Stage:
                                     |  Unreviewed
    Has patch:  1                    |      Needs documentation:  0
  Needs tests:  0                    |  Patch needs improvement:  0
Easy pickings:  0                    |                    UI/UX:  0
-------------------------------------+-------------------------------------
Changes (by akulakov):

 * has_patch:  0 => 1


Old description:

> 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.

New description:

 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

--

--
Ticket URL: <https://code.djangoproject.com/ticket/24643#comment:2>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.d0fcae427700398d34e7a746f9f8c988%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to