On Sat, Jul 10, 2010 at 7:24 AM, Russell Keith-Magee <russ...@keith-magee.com> wrote: > On Sat, Jul 10, 2010 at 12:49 AM, Carl Meyer <carl.j.me...@gmail.com> wrote: >> On Jul 7, 7:11 pm, Graham Dumpleton <graham.dumple...@gmail.com> >> wrote: >> [snip] >>> web application, to be a well behaved WSGI citizen, should honour >>> SCRIPT_NAME setting as supplied by the server, and ensure that ways >>> are provided such that everything in the users code, including >>> configuration, urls or settings files, can be expressed relative to >>> the URL that the application is mounted at, thereby avoiding as much >>> as possible any need for a user to modify their code base when >>> deploying to a new environment at a different location in URL >>> namespace. >> >> IMO one root problem here (which has been discussed before) is that >> settings.py conflates "deployment config" with "application config" >> and thus tends to lead to fuzzy thinking about which is which (which >> causes problems especially for larger organizations with separate >> teams for development and ops). Application config should not have to >> change between different deployments of the same codebase; deployment >> config almost certainly will. >> >> The status quo makes LOGIN_URL (and friends) themselves a mishmash of >> deployment config and application config; i.e. the initial >> "application mount point" portion is deployment config, and the rest >> is clearly application config (it would only change if the URLconf >> changes). This seems like a bad thing to me: the ops team shouldn't >> have to understand the internal layout of the application's urls in >> order to deploy it correctly. > > This is a certainly a criticism I would agree with. An improved app > config/deployment config distinction is a broad goal that is worth > striving for. > >> Wouldn't it be most sensible to treat the URL mount point similarly to >> hostname, since they are really just two pieces of the same data: the >> deployed root URL of the application? (Practically speaking, this >> could mean a new field in contrib.sites.Site, or allowing/condoning >> "example.com/something" as a value for the domain field, and extending >> RequestSite to do the same by checking SCRIPT_NAME). > > I'm not sure I understand exactly what you're describing here. Lets > say we modify Site, and I have the mount point data described in my > Site.objects.get_current() instance; are you proposing that anywhere > that you use LOGIN_URL, we should be prepending site.mount_point (or > whatever the bikeshed looks like)? > > If so, how do we get from here to there? For better or worse, if > you're deploying a Django site at a non-root SCRIPT_NAME, you will > have a LOGIN_URL that includes that SCRIPT_NAME; how do you propose > that we transition to a mount-point based interpretation? > > Yours, > Russ Magee %-) > > -- > 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 seems to me the easy answer is to always pass it through "redirect", which will do the right thing on an absolute URL, but also handle reverse. 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.
