On Wed, Dec 16, 2009 at 2:53 PM, Mike Malone <mjmal...@gmail.com> wrote: > 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. > > >
It allows an object to return a URL that already has it's domain defined (as might happen for a SaaS site with custom subdomains). 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.
