Opened 11 years ago

Closed 11 years ago

Last modified 11 years ago

#20980 closed Cleanup/optimization (wontfix)

Inconsistant MRO in BaseDateListView and BaseDayArchiveView

Reported by: django@… Owned by: nobody
Component: Generic views Version: 1.5
Severity: Normal Keywords:
Cc: Triage Stage: Unreviewed
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

I have a class like this:

class ReportView(DateDetailView, BaseDayArchiveView, BaseMonthArchiveView):

Which raises an exception: Cannot create a consistent method resolution order (MRO) for bases DateMixin, ContextMixin

This is due to the order of basses on BaseDateListView. I've attached a patch that solves the problem.

It's useful for showing the details of one object, with a list of other related dated objects.

Attachments (1)

generic_dates_MRO_fix.patch (485 bytes ) - added by django@… 11 years ago.
Patch

Download all attachments as: .zip

Change History (3)

by django@…, 11 years ago

Attachment: generic_dates_MRO_fix.patch added

Patch

comment:1 by Marc Tamlyn, 11 years ago

Resolution: wontfix
Status: newclosed

I would be generally worried about what you're trying to do here. There's a *lot* of pieces of functionality in this code you're trying to use at once. In particular, you've got both SingleObjectMixin and MultipleObjectMixin in your class hierarchy. Also, you've got multiple implementations of get_dated_items.

This seems a heavy edge case to me. I think it's the territory you should be writing your own view rather than trying to to mix together the pieces Django provides. You may have more luck composing the lower level components of the views you're using at the moment so you have better control over the MRO.

I'm going to close this, as we simply can't support every possible inheritance scenario. The patch is pretty innocuous, but the motivation is flawed.

comment:2 by django@…, 11 years ago

I'm aware of the multiple get_dated_items. I have get method which avoids super calls for this reason. It's expected that a class with a diamond dependency graph will resolve conflicts between the base classes. With the MRO conflict resolved the code works fine. I have a view which shows a report, a list of reports on the same day, and a calendar with links to the other days that have reports:

    def get(self, request, **kwargs):
        self.object = self.get_object()
        self.date_list, self.object_list, extra_context = BaseDayArchiveView.get_dated_items(self)

        context = self.get_context_data(object_list=self.object_list,
                                        date_list=BaseMonthArchiveView.get_dated_items(self)[0],
                                        object=self.object,)
        context.update(extra_context)
        return self.render_to_response(context)

It may be strange, but it's very powerful to be able to piece views together. Just these six lines of code and I've got the page described above. Thanks for your time looking at my patch.

Note: See TracTickets for help on using tickets.
Back to Top