On Thu, 2008-10-02 at 12:37 +0200, Thomas Guettler wrote: > Malcolm Tredinnick schrieb: > > To understand the problem you're trying to solve a bit better: why do > > you want it to add a (fake) script name in the non-HTTP case? > > Example: Send an email via cron that includes a link which > was created with reverse(). The method which creates the > link (and adds the http://servername/) should be callable within > http context, too.
Yes, that's a reasonable use-case. I'm still not in love with the idea of using FORCE_SCRIPT_NAME, since it doesn't then parallel the behaviour with other web-servers that don't need it to be set (and setting it just for the shell case then means the HTTP behaviour won't really match what the webserver says). A way to generate the "real" URL for a particular install via a setting would be useful, though. The solution I currently prefer here is a new type of settings variable (I've actually been thinking about this for some other situations like TEMPLATE_DEBUG, but it applies here, too): a setting that, if not set, will always copy the value of some other setting. So, in this case, we have something like SITE_PREFIX that, if set, will be used for the sort of thing you're thinking about and, if not set, will follow FORCE_SCRIPT_NAME (or, in the HTTP context, the SCRIPT_NAME value that the web request has set up). I mostly just want to keep the functionality you're looking for separate from FORCE_SCRIPT_NAME so that your functionality is available no matter what the setup. I think this won't be too hard to fix. I'll add it to my list. Regards, Malcolm --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
