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.
