[Django] #20980: Inconsistant MRO in BaseDateListView and BaseDayArchiveView
Django
--------------------------------------+--------------------
Reporter: django@… | Owner: nobody
Type: Cleanup/optimization | Status: new
Component: Generic views | Version: 1.5
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 1
Easy pickings: 0 | UI/UX: 0
--------------------------------------+--------------------
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.
--
Ticket URL: <https://code.djangoproject.com/ticket/20980>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
Reporter: django@… | Owner: nobody
Type: | Status: closed
Cleanup/optimization | Version: 1.5
Component: Generic views | Resolution: wontfix
Severity: Normal | Triage Stage:
Keywords: | Unreviewed
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by mjtamlyn):
* status: new => closed
* needs_better_patch: => 0
* resolution: => wontfix
* needs_tests: => 0
* needs_docs: => 0
Comment:
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.
--
Ticket URL: <https://code.djangoproject.com/ticket/20980#comment:1>
Django
Reporter: django@… | Owner: nobody
Type: | Status: closed
Cleanup/optimization | Version: 1.5
Component: Generic views | Resolution: wontfix
Severity: Normal | Triage Stage:
Keywords: | Unreviewed
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Comment (by django@…):
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.
--
Ticket URL: <https://code.djangoproject.com/ticket/20980#comment:2>