| 1 | | Perdon my french, i sometimes forget internet is serious business. |
| 2 | | |
| 3 | | So, i believe that templateview should have a template_context_response() method to encapsulate the business between template and context, ie. when not using get_context_data as validated in #16744 opened by Reinout Van Rees (the Django teacher, met at djangocon cardiff we shared AFPY's airbnb hehe) seven year ago participated to the CBV revolution with a lot of hackers i have always admired for the beauty of their code (perdon my french), I credit the visionarism of this movement, Marc Tamlyn, commiter of 58683e9c82d, from and the participants of ticket #167433 who maintained their patch Claude Paroz Andrew Godwin and look at all these hacker names in the ticket it's amazing and oh my what i just found in comments is just so like , i would'nt like it if i was django : |
| 4 | | |
| 5 | | > I'm going to have to re-write part of my introductory views-and-templates chapter, as class based views look silly without this patch in |
| 6 | | |
| 7 | | I'm sorry for not having the classy class of my friend Reinout, the famous django philosopher. |
| 8 | | |
| 9 | | > Unless I missed something, super().get() will call the TemplateView implementation, even if you override get() in a subclass. |
| 10 | | |
| 11 | | That's True unless YourFooDetailView inherits from YourProjectDetailView which would inherit from django.views.generic.DetailView. |
| 12 | | |
| 13 | | When you work as a Django user, you often want to add a project-specific layer between your actual user facing views and django views, ie. to refactor common features you have in all your {List,Detail,Update,Create,Form,Object,Model}View classes accross the project's app. Because when you are a coder with love you usually end up with your own default {create,delete,update,list,detail} templates (cause instead of {% extends 'myapp/base.html' %} in 'myapp/foo_list.html', you have {% extends 'list.html' %}, not only for the love of beauty, but to refactor as much template code as possible. |
| 14 | | |
| 15 | | And anyway, I think get_context_data() deserves to be removed from Django's public API, this is made to support legacy templates, new templates just use {{ view.object }} than {{ object }} because then they make @object a memoized property which they can always use in {dispatch,get,post,delete,options} methods instead of thinking they're paid by the quantity of lines of code and take pride in overriding and decorating get_context_data() for no reason thanks to the visionary who made view=self a default in CBV. |
| 16 | | |
| 17 | | Maybe what I'm saying doesn't make any sense to anybody than myself lol but at least you can point-godwin me because i don't consider the resolution of this ticket worksforme, but don't take it personnaly, you know i still admire you from the deepest of my heart Tim <3 |
| 18 | | |
| 19 | | But deep in your heart, you know that love between a context and a template must not be coupled to the get method's callback in TemplateView but should indeed be in its own method ending with: |
| 20 | | |
| 21 | | class TemplateView..: |
| 22 | | def get..: |
| 23 | | return self.template_context_love() |
| 24 | | |
| 25 | | Then you can: |
| 26 | | |
| 27 | | def post..: |
| 28 | | love() |
| 29 | | return self.template_context_love() |
| 30 | | |
| 31 | | Instead of |
| 32 | | |
| 33 | | def post..: |
| 34 | | return self.get() # but i just want template_context love not all my parent get logic :'( |
| 35 | | |
| 36 | | With LOVE |
| 37 | | ∞ |
| | 1 | But after considering every option it seems like adding a comment in code would be even useless for this I think an interresting story brought this issue but there's nothing to fix in django so TemplateView.get works for me very well by the way that's actually what i already have actually, sry for the noise <3 |