On Thu, Jul 8, 2010 at 7:11 AM, Graham Dumpleton <graham.dumple...@gmail.com> wrote: > Can the following issue be revisited. > > http://code.djangoproject.com/ticket/8906 > > Conversation about it at: > > http://groups.google.com/group/django-users/browse_frm/thread/c457599caab6e87d/b70e1f56ad38f4cb > > This is another of those issues where Django isn't being particular > friendly to people who want to have relocatable sites. That is, where > in in one environment it may be mounted at root of site (eg. > development server), but where it has to be mounted at a sub URL in > another (eg. production).
While I can see the issue you're referring to, I'm not sure I agree with your diagnosis. The site is perfectly relocatable. You just need multiple settings files -- in development, settings will contain LOGIN_URL='/login'; in production, settings will contain, LOGIN_URL='/mount_point/login'. When you move from development to production you almost always (in my experience) have a separate settings file, if only to separate database configurations, contact emails, etc. Adding a couple of extra settings for some values that actually *are* deployment specific doesn't seem especially onerous to me. >It also relates to the whole problem where a > 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. > > Yes I know Jacob knocked it on the head last time, but this problem > keeps occasionally popping up because it seems not to be obvious that > people need to go and change stuff when mounting an application at a > sub URL. Personally, I see this as a case of explicit vs implicit. As currently defined, LOGIN_URL points to the login URL. Period. Under the proposed patch, the onus is on every possible script to ensure that the script prefix has been set correctly. WSGI will do this by default, but WSGI scripts aren't the only consumers of Django code. Personally, I spend almost as much time on background processing scripts for sites I support as I do on pages served via HTTP. So - is it more confusing to require that a settings file explcitly define the full URL, or to expect every script to configure itself to populate the magic SCRIPT_NAME variable? Jacob's position (and I find myself agreeing with this position) is that it's less confusing to require the settings file to be explicit. > The solution may be the introduction of a new section in the > Django documentation outlining all the things that need to be done > differently when mounting site at a sub URL. At least then people cant > complain the requirements aren't documented even if some may think it > is a silly requirement to begin with. :-) This is certainly worth doing. Submissions welcome. 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.
