#28999: URL Reverse does not work for CBV (Class Based Views)
---------------------------------+--------------------------------------
Reporter: airstandley | Owner: nobody
Type: Bug | Status: new
Component: Generic views | Version: 2.0
Severity: Normal | Resolution:
Keywords: url reverse cbv | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
---------------------------------+--------------------------------------
Comment (by airstandley):
I think it may be possible to fix by simply caching the view function when
it is created and from then on returning the cache, but I haven't yet
looked into how this would effect the initwargs.
Hmm, I'm not sure how to best describe my preference. It's part of a
larger experimentation with the framework.
I'm trying to experiment with using {{{get_absolute_url}}} on my models,
and I have CBV DetailView classes for my models. Firstly it seems round-
about to use a URL name that represents a url->view mapping when I know
the view I want. The View Class for a given Model is a core relationship
that should never change, if someone uses my Models they should want to
use my Views for those model. The URL name "should" not change, but it is
perfectly reasonable someone may want to use my models and my views
without using my urlconf. The url schema (an thus URL name) could be
considered a separate matter to the models/views so I would like to de-
couple these things in code for my Models/Views.
I hope that makes sense?
Secondly I would ideally like to find a way to create a 'reverse' that
find the url regardless of the namespacing. (So a user of my app would not
have to update my models.py if they wanted to include my urlconf under a
namespace). Obviously this won't work with URL names, but since every
function should have a unique hash, I believe I can make it work using
view functions... But that is currently impossible for CBV because of this
issue.
I'm probably trying to be far to fancy for my own good here, but that is
the reason for my preference.
I admit, it is likely that for 99% of people, documenting that it doesn't
work would probably be a satisfactory fix.
--
Ticket URL: <https://code.djangoproject.com/ticket/28999#comment:2>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/069.f0979fcaa9292abfa9ed8254721a2f2f%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
