On Tue, Jan 10, 2012 at 2:05 PM, jrief <jacob.r...@gmail.com> wrote: > But the mixin plugins are not derived from django.views.generic.DetailView, > otherwise the main app's DetailView would obtain a diamond shaped > inheritance.
Well, that is evident isn't it - they are mixins. If they were derived from DetailView, they would be subclasses. Besides which, with python multiple inheritance, you don't get a diamond, you get a chain, see below. > > And django.views.generic.detail.BaseDetailView.get calls get_context_data > only once, so I don't see how the plugins shall "deliver" their contexts. Welcome to the world of the MRO - Method Resolution Order. This SO post gives a good example of how MRO works: http://stackoverflow.com/questions/2010692/what-does-mro-do-in-python This page*, particularly the diagram in the "Argument passing, argh!" section should make it clearer how a diamond inheritance is handled (viz. it's not a diamond): http://fuhm.net/super-harmful/ Got that? OK, so when you have a class like this: class MyView(Mixin1, Mixin2, SomeSuperView): then the MRO for this class will look something like this: (MyView, Mixin1, Mixin2, SomeSuperView, object) When you call MyView.get_context_data and call super(MyView, self).get_context_data, it will first try Mixin1.get_context_data, which if exists should call super(Mixin1, self).get_context_data, and so on up the MRO stack. Cheers Tom * super is not harmful, no matter what that page says. It is just that you must be consistent when using it. -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
