Changes between Initial Version and Version 1 of Ticket #28943, comment 16
- Timestamp:
- Mar 6, 2018, 2:55:33 PM (7 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #28943, comment 16
initial v1 3 3 That's True unless YourFooDetailView inherits from YourProjectDetailView which would inherit from django.views.generic.DetailView. 4 4 5 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. 5 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 code as possible. 6 6 7 7 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.