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 }}).
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.
