> The way i see it (which may be wrong), this is not a proposal to make > the request object global or replace/refactor the contrib.site app. In > fact, some of the use cases mentioned strike me as things that would > require overriding the default get_absolute_url method anyway. It > seems to me like everyone is arguing over things outside the scope of > this proposal.
Actually the fundamental disagreement (as far as I can tell) is over whether the absolute URL should be built using information pulled from various application settings (Site module, settings file, etc) or information pulled from the currently active request. In my opinion, using the Site module and settings files is damn annoying. I never use the Site module, and in my experience having to change the "FRONTEND_URL" of your app every time you push to a different environment is tedious and a frequent source of subtle problems. Moreover, the request information in your current request _should_ always be correct. If someone requests a non-canonical URL you should redirect (CNAME, 301, etc) to the canonical URL. If your load balancer isn't sending the correct headers then the load balancer is broken, not Django. That said, it sounds like there are a number of special cases where it would be useful to override these settings. So maybe the best corse of action is to try to use the configured Site information and fall back on "RequestSite", which uses information from the currently active request. Thoughts? Mike -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
