On Wed, Dec 16, 2009 at 11:10 AM, Alex Gaynor <alex.gay...@gmail.com> wrote: > On Wed, Dec 16, 2009 at 2:02 PM, Mike Malone <mjmal...@gmail.com> wrote: >>> 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. >> >> >> > > I am very strongly against making the request a thread local. We have > used thread locals in a few places (urlconf and i18n are the obvious > ones), and while they don't put a smile on my face they do serve a > very narrow, well defined purpose, in places where it would often be > impossible to get the appropriate context in. > > However, I think making the entire request object (or even just the > domain + SSL state) is an incredibly open ended solution that is rife > with potential for abuse. > > However, I come bearing a solution! > > Instead of having get_url() or whatever the method is named return a > string, have it return a URL object, specifically instantiated with > REQUEST_HOST for it's host value. Then the caller can pass this value > around and when it gets returned to the appropriate place where the > request is in scope it can interpolate it's values into the URL object > appropriately. This may necessitate adding a template filter ({{ > obj.get_url|interpolate_request:request }}).
How's that different than the current situation, where we return an absolute URL reference that can be converted into an absolute URL using request.build_absolute_uri? Mike > > Alex > > -- > "I disapprove of what you say, but I will defend to the death your > right to say it." -- Voltaire > "The people's good is the highest law." -- Cicero > "Code can always be simpler than you think, but never as simple as you > want" -- Me > > -- > > 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. > > > -- 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.
