I'm trying to wrap my head around Django concepts, but I struggle with the URLResolver reverse_lazy(). As far as I know, I have to use reverse_lazy() when I want to reverse to an URL that has not been loaded. So when I create a CBV and state a success_url, I use reverse_lazy(). This means that the URL is not imported when the file executes.
This is confusing to me because I think the server loads all the URLs while starting before executing anything. So how come the URL is not loaded in time of execution?
I would be very happy if someone would give me an answer to this.
Well, first of all, the URL resolver itself is lazy, so loading happens when the first call to resolve() or reverse() is made (usually on the first request). But that doesn't matter much in this case.
When the URL resolver is being initialised, it imports your URL configuration, which in turn imports your views. So at the time your view is imported and success_url is set, the resolver is only halfway through its initialisation. Calling reverse() at this point would not work since the resolver doesn't have all the information yet to reverse the view name.
Related
How do you return a url using get_success_url(self) in django without using reverse for a generic view? Basically, I want to have something as below.
def get_success_url(self):
url = self.object.url # This is a charfield with "https://stackoverflow.com/questions/ask"
return url
I know that people often use reverse when returning a url, but I would like do it like above. Thank you, and please write any questions you have. By the way, I never tested the above code, but I don't know if it will work properly.
"reverse(..)" is part of the django logic to store the url structure in urlpatterns in ONE place and then in the whole code refere to it in the moment of the request being executed via the name. If you do not want to follow that logic - feel free to store anything you like in your "object.url" and return it like you propose. You then just do not follow the django urlpattern idea. Up to you to decide if that is important or "right" in your case.
If the url targets outside our own server space, reverse is anyway not usefull as those urls are not part of your urlpattens.
I have the following urlpatterns, in this order:
url(r'^([^//]*)/forum/topics/$', showThreadTopics),
url(r'^([^//]*)/$', redirectFrontPage)
I go to:
http://localhost:8000/xxx/forum/topics/
showThreadTopics is called and the page is correctly shown. However, I happened to have a breakpoint set in redirectFrontPage and saw that this function is also called. This happens every time and I can print statements from it. It has no effect on the final result and does not cause any apparent network activity when looking in Firebug. There is nothing special about showThreadTopics. It just gets some data and renders them. Actually, redirectFrontPage is called with any of my urls.
How is that even possible? How do I avoid it? I have that last urlpattern because if someone types
www.mysite.com/users_site_name
then I want to redirect it to
www.mysite.com/users_site_name/home
I would guess that a static reference on the page, to something like a CSS, JS or image file, is being intercepted by that URL, since it captures everything that isn't previously captured by anything else. It may even be the browser's automatic request of a favicon.
I am trying to write some tests for a Django application I'm working on but I haven't yet decided on the exact urls I want to use for each view. Therefore, I'm using named urls in the tests.
For example, I have a url named dashboard:
c = Client()
resp = c.get(reverse('dashboard'))
This view should only be available to logged in users. If the current user is anonymous, it should redirect them to the login page, which is also a named url. However, when it does this, it uses an additional GET parameter to keep track of the url it just came from, which results in the following:
/login?next=dashboard
When I then try to test this redirect, it fails because of these additional parameters:
# It's expecting '/login' but gets '/login?next=dashboard'
self.assertRedirects(resp, reverse('login'))
Obviously, it works if I hard code them into the test:
self.assertRedirects(resp, '/login?next=dashboard')
But then, if I ever decide to change the URL for my dashboard view, I'd have to update every test that uses it.
Is there something I can do to make it easier to handle these extra parameters?
Any advice appreciated.
Thanks.
As you can see, reverse(...) returns a string. You can use it as:
self.assertRedirects(resp, '%s?next=dashboard' % reverse('login'))
I have an entry in my urls.py that acts as a catch-all which loads a simple view if it finds an appropriate page in the database. The problem with this approach is that the URL solver will then never fail, meaning that the APPEND_SLASH functionality won't kick in - which I need.
I'd rather not have to resort to adding a prefix to the static page URLs to stop it being a catch-all. I do know about flatpages, which uses a 404 hook rather than an entry in urls.py, and I had kinda hoped to avoid having to use it, but I guess this problem might be exactly the kind of reason why one would use it.
Any way round this problem or should I just give in and use flatpages?
Make sure that your catch-all URL pattern has a slash at the end, and that the pattern is the last in your URLconf. If the catch-all pattern doesn't end with a slash, then it will match stray URLs before the middleware tries appending a slash.
For example, use r'^.*/$' instead of r'^.*' as your last pattern.
To do the same, but pass the url to the view as a named argument, use r'^(?P<url>.*)/$'.
The statement if it finds an appropriate static page in the database seems like your static pages are not quite static so, you either pass your links through urls.py (just like you do now), or you extract those pages from the DB, put them in a directory and configure that directory as one for serving static files
I'm having a problem with configuring Flatpages in Satchmo. I've used them before, in a pure django app, but now it just doesn't work, returning 301 http error when I'm trying to enter a flatpage-configured site.
What I've done to configure it:
added the middleware "django.contrib.flatpages.middleware.FlatpageFallbackMiddleware" to MIDDLEWARE_CLASSES as last in the list,
configured example pages in admin module.
Simply what the docs say about flatpages config.
I'm feeling helpless. Don't know how could I debug this issue. Any thoughts on that?
And of course help appreciated.
Thanks to suggestion by Peter I've managed to narrow the problem to my urls.py file, for the satchmo shop.
The urlpatterns has only one entry:
(r'', 'django.views.generic.simple.redirect_to', {'url' : '/shop/'}),
This version does not work and moreover interfere with flatpages. But disabling flatpages from MIDDLEWARE_CLASSES and adding it to urls.py like the snippet below works:
(r'^(?P<url>.*)$', 'django.contrib.flatpages.views.flatpage'),
(r'', 'django.views.generic.simple.redirect_to', {'url' : '/shop/'}),
However next problem is with the redirection from / to /shop/. With the above config it results in infinite loop.
Perhaps you know the reason for that behavior (redirect overriding flatpage) and maybe You could suggest some working solution to this problem or what should be done with requests to /.
It returns 301? That's Page Moved Permanently (HttpResponsePermanentRedirect) and there are no references to that in the flatpages directory so I don't think it's coming from there. In fact there are only about 5 references to HttpResponsePermanentRedirect in all of the standard 1.1.1 release.
Possible approaches:
Comment out the FlatPages middleware and see if the error changes (I'm betting it won't).
Try changing the order of your MIDDLEWARE classes and see if things change.
When presenting a problem like this it's better to get very specific by showing the exact code from applicable portions of settings.py (or whatever) and by giving other things like precise URLs and the urls.py patterns you are trying to match.
Update:
OK, some random thoughts:
The pattern (r'^(?P<url>.*)$', 'django.contrib.flatpages.views.flatpage'), will match anything. Any patterns after it will never be seen.
flatpages doesn't work by being called directly, it does its magic in middleware. It looks for 404 responses (Page Not Found) and then looks to see if that path exists in its table. If so, it calls a view that renders the page, etc. etc. If it doesn't find a match it let's the 404 continue on through middleware processing.
The pattern (r'', 'django.views.generic.simple.redirect_to', {'url' : '/shop/'}), will match anything (I just tested it). If you want to match an empty path, use r('^$', etc.). This is the source of your infinite loop.
If you are new to regular expressions the Django urls.py file can seem like F*cking Magic. I recommend starting very simply and add one rule at a time. Do some quick tests to ensure that the new rule a) matches stuff you want it to match, and b) doesn't match stuff it shouldn't. In particular, make sure that some of the rules that occur later in the file are still reachable. In this case they wouldn't have been which should have raised a red flag.