[Django] #16963: relocate base View class to views.base from views.generic.base
Django
--------------------------------------+--------------------
Reporter: ptone | Owner: nobody
Type: Cleanup/optimization | Status: new
Component: Generic views | Version: SVN
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 1
Easy pickings: 0 | UI/UX: 0
--------------------------------------+--------------------
Much thought went into the technique used for exposing a python class to
the URLconf and making it sane in the context of the View contract in a
thread safe way.
However, the base class, View, is located in the generic module, implying
that it is somehow tied to generic views.
I propose that this base class is a good default for anyone doing class-
based views in Django, and that its use outside the context of generic
views should be made explicitly obvious by relocating the location of the
code outside of the generic views module.
--
Ticket URL: <https://code.djangoproject.com/ticket/16963>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
Type: Cleanup/optimization | Status: new
Component: Generic views | Version: SVN
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 1
Changes (by russellm):
* needs_docs: => 0
* needs_better_patch: => 1
* needs_tests: => 0
* stage: Unreviewed => Accepted
Comment:
Makes sense to me, and the patch looks good, except for docs. There is a
reference to the base view in the CBV reference docs, which needs to be
updated.
--
Ticket URL: <https://code.djangoproject.com/ticket/16963#comment:1>
Django
Type: Cleanup/optimization | Status: new
Component: Generic views | Version: SVN
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Changes (by ptone):
* needs_better_patch: 1 => 0
Comment:
Updated to fix docs (a couple errant refs to django.db.views also fixed)
Hopefully #16807 will further improve the docs, but the latest patch
should at least be complete
--
Ticket URL: <https://code.djangoproject.com/ticket/16963#comment:2>
Django
Type: Cleanup/optimization | Status: new
Component: Generic views | Version: SVN
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Comment (by bpeschier):
To be honest, all classes in {{{views/generic/base.py}}} feel like they
could live one package up. These classes and mixins are all ... uhm...
basic for CBV and not specifically tied to generic views.
--
Ticket URL: <https://code.djangoproject.com/ticket/16963#comment:3>
Django
Type: Cleanup/optimization | Status: new
Component: Generic views | Version: SVN
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Comment (by ptone):
Replying to [comment:3 bpeschier]:
> To be honest, all classes in {{{views/generic/base.py}}} feel like they
could live one package up. These classes and mixins are all ... uhm...
basic for CBV and not specifically tied to generic views.
I think part of the issue is that the history of "generic" views were that
they were only viable for the most basic of the generic cases. The
current generic views are more of a toolkit, and so will be far more
flexible and useful. So the word generic is perhaps no longer the best
descriptor.
However I think that leaving these "toolkit" pieces in a submodule of
views makes sense, while moving the fundamental implementation of exposing
a class as a view-thread safe instance is worthy of being the base views
module.
only the View class deals with the fundamental interaction of python
classes with the Django request/response flow and infrastructure - while
the other classes are just "one way of doing it" even thought those in
base.py are pretty hard to argue with.
--
Ticket URL: <https://code.djangoproject.com/ticket/16963#comment:4>
Django
Reporter: ptone | Owner: ptone
Type: Cleanup/optimization | Status: assigned
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Changes (by ptone):
* owner: nobody => ptone
* status: new => assigned
--
Ticket URL: <https://code.djangoproject.com/ticket/16963#comment:5>
Django
Reporter: ptone | Owner: ptone
Type: Cleanup/optimization | Status: assigned
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Comment (by aaugustin):
I understand the proposal, but in my opinion, the advantages of moving
this code to a slightly more appropriate location aren't really worth :
- either the deprecation path and backwards-incompatibility;
- or keeping backwards-compatible imports forever, so that there are
effectively two ways to import these classes.
So -0 from me.
--
Ticket URL: <https://code.djangoproject.com/ticket/16963#comment:6>
Django
Reporter: ptone | Owner: ptone
Type: Cleanup/optimization | Status: assigned
Component: Generic views | Version: master
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by timo):
* needs_better_patch: 0 => 1
Comment:
No longer applies cleanly.
--
Ticket URL: <https://code.djangoproject.com/ticket/16963#comment:7>
Django
Reporter: ptone | Owner: ptone
Component: Generic views | Version: master
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by ptone):
* status: assigned => closed
* resolution: => wontfix
Comment:
I now think this should just be in a list of things we would have done
slightly different about CBVs
--
Ticket URL: <https://code.djangoproject.com/ticket/16963#comment:8>