Thanks Graham. I guess I won't be hiking that trail.
On Aug 29, 6:40 pm, Graham Dumpleton <[EMAIL PROTECTED]>
wrote:
> On Aug 30, 12:20 am, Greg Fuller <[EMAIL PROTECTED]> wrote:
>
> > Thanks for the replies.
>
> > I like the middleware solution, if you can modify settings variables
> > during middleware processing. The documentation warns against altering
> > settings at runtime.
>
> > What are the consequences of ignoring the warning?
>
> You can't use middleware approach to modify stuff in settings module
> as I believe the information is only pulled from there on first
> initialisation of Django. So, middleware can only work where it
> doesn't involve changing settings values. That is, where the handler
> code itself acts based on the derived values and not the underlying
> Django engine. Only exception would be if components being used allow
> you to override stuff pulled from settings on a per request basis.
>
> Graham
>
> > Eric, I don't think setting up multiple projects would work well in
> > this case. I didn't make it clear in my original post, but there
> > would be more than two sites, more than 2 template directories, and
> > possibly other settings based on http header information. The variety
> > of possible combinations might get a little unweildy and require too
> > many instances of django.
>
> > Graham: Wow, that is a lot :). In addition to what I mentioned above,
> > I would like all this to be as easy as possible to configure (the
> > software will be distributed).
>
> > --Greg
>
> > On Aug 29, 8:00 am, Graham Dumpleton <[EMAIL PROTECTED]>
> > wrote:
>
> > > On Aug 29, 8:50 pm, Erik Allik <[EMAIL PROTECTED]> wrote:
>
> > > > For the iPhone templates issue, I'd set up two projects instead of one
> > > > -- one for regular browsers, one for the iPhone. Then I'd simply
> > > > redirect from the regular one to the iPhone one as needed. Although
> > > > this has the negative side effect of having more than one URL per
> > > > resource, but you could also customize content visibility.
>
> > > > Same for the second example -- normally one project is set up per
> > > > domain.
>
> > > > Erik
>
> > > > On 29.08.2008, at 1:24, Greg Fuller wrote:
>
> > > > > I would like a way to to adjust settings based on information in the
> > > > > http header. I've seen a similar question asked before, but I don't
> > > > > need all the django request object, just the http header information.
> > > > > More specifically, user_agent, http_host, and path_info.
>
> > > > > Here are two examples of the sort of things I would like to do:
>
> > > > > # use iphone template if appropriate
> > > > > if http_header['USER_AGENT'].find('iphone'):
> > > > > TEMPLATE_DIRS = (
> > > > > os.path.join(cur_dir_path, 'template_sets/' + 'iphone'),
>
> > > > > # set SITE_ID for MyOtherDomain.com
> > > > > if http_header["HTTP_HOST"].find('myotherdomain.com'):
> > > > > SITE_ID = 2
>
> > > > > Does anyone know if this can be done?
>
> > > I am reasonably sure both of you could do what you want using
> > > mod_wsgi. That is based on user agent map to different instances of
> > > Django where only difference is the settings file that was used.
> > > Importantly, in the process using the same host name and URLs.
>
> > > I'll explain how to setup Apache configuration etc, but will not be
> > > surprised if I loose you along the way. :-)
>
> > > First off, for this example I'll use daemon mode of mod_wsgi. What we
> > > will do here is create two distinct mod_wsgi daemon process groups to
> > > hold the two Django instances. I'll show it as two single but
> > > multithreaded processes (ie., the default), but you can change that.
>
> > > WSGIDaemonProcess config-1 display-name=%{GROUP}
> > > WSGIDaemonProcess config-2 display-name=%{GROUP}
>
> > > With display-name option, these show separately in 'ps' output as:
>
> > > 70 2802 2800 0 0:00.01 ?? 0:00.01 (wsgi:config-1) -D
> > > FOREGROUND
> > > 70 2803 2800 0 0:00.01 ?? 0:00.01 (wsgi:config-2) -D
> > > FOREGROUND
>
> > > Am then going to force the main interpreter in each process to be used
> > > for handling any requests. This is actually to make it easier as need
> > > to name the interpreter within the processes for next step.
>
> > > WSGIApplicationGroup %{GLOBAL}
>
> > > What we want to do now is setup each of those two process with
> > > different environment. Specifically, we want to set
> > > DJANGO_SETTINGS_MODULE environment variable to be different for each.
> > > Normally we do this in the WSGI script file, but we will only have one
> > > WSGI script file and no way to determine what to make the setting when
> > > WSGI script file is first loaded. What we instead do is use ability to
> > > preload a script file when processes are started.
>
> > > WSGIImportScript /Users/grahamd/Sites/config-1.wsgi \
> > > process-group=config-1 application-group=%{GLOBAL}
>
> > > WSGIImportScript /Users/grahamd/Sites/config-2.wsgi \
> > > process-group=config-2 application-group=%{GLOBAL}
>
> > > The options to the directive allow us to indicate a different file to
> > > preload for each process.
>
> > > For the contents of 'config-1.wsgi' have:
>
> > > import os
> > > os.environ["DJANGO_SETTINGS_MODULE"] = "site.settings1"
>
> > > For the contents of 'config-2.wsgi' have:
>
> > > import os
> > > os.environ["DJANGO_SETTINGS_MODULE"] = "site.settings2"
>
> > > To configure mod_wsgi to host Django application itself, would
> > > normally have:
>
> > > Alias /media/ /usr/local/django/mysite/media/
>
> > > <Directory /usr/local/django/mysite/media>
> > > Order deny,allow
> > > Allow from all
> > > </Directory>
>
> > > WSGIScriptAlias / /usr/local/django/mysite/apache/django.wsgi
>
> > > <Directory /usr/local/django/mysite/apache>
> > > Order deny,allow
> > > Allow from all
> > > </Directory>
>
> > > The WSGI script file would normally be:
>
> > > import os, sys
> > > sys.path.append('/usr/local/django')
> > > os.environ['DJANGO_SETTINGS_MODULE'] = 'mysite.settings'
>
> > > import django.core.handlers.wsgi
>
> > > application = django.core.handlers.wsgi.WSGIHandler()
>
> > > but we don't want that, and instead we want:
>
> > > import sys
> > > sys.path.append('/usr/local/django')
>
> > > import django.core.handlers.wsgi
>
> > > application = django.core.handlers.wsgi.WSGIHandler()
>
> > > The difference here being that we have dropped setting of
> > > DJANGO_SETTINGS_MODULE as this was done from preloaded scripts.
>
> > > As to settings1 and settings2, these would be in same directory as
> > > where settings file would normally be. They could be a complete copy
> > > of original settings files with each modified as per requirement, ie.
> > > setting TEMPLATE_DIRS differently. Or you could do:
>
> > > from settings import *
>
> > > TEMPLATE_DIRS = "......."
>
> > > That is import everything out of main settings file and just override
> > > what you want.
>
> > > Now, there is one final bit missing from all of this because if we use
> > > that as is, the requests will actually be handled in embedded mode as
> > > haven't delegated that requests actually be run in the daemon
> > > processes. What we will now do is provide a dispatch routine so can
> > > automatically select which daemon process is used for requests.
> > > Configuration for that is:
>
> > > WSGIDispatchScript /Users/grahamd/Sites/dispatch.wsgi
>
> > > The content of the dispatch script would then contain:
>
> > > def process_group(environ):
> > > agent = environ.get("HTTP_USER_AGENT", "")
>
> > > if agent.find("Safari") != -1:
> > > return "config-1"
>
> > > return "config-2"
>
> > > In this example what it is going to do is return that 'config-1'
> > > process group should be used if Safari web browser is used, otherwise
> > > use 'config-2' process group. Obviously you do proper matching of user
> > > agent string as appropriate.
>
> > > Now, I used daemon processes and the dispatch script to make it more
> > > obvious but in case you needed to complicated things based on headers,
> > > but other things could be done instead which may be a bit simpler.
>
> > > First off you could do away with the dispatch script. That is, don't
> > > use WSGIDispatchScript. Instead should be able to use something like:
>
> > > BrowserMatch .* PROCESS_GROUP=config-2
> > > BrowserMatch Safari PROCESS_GROUP=config-1
>
> > > WSGIProcessGroup %{ENV:PROCESS_GROUP}
>
> > > That is, use mod_setenvif to match browser instead of dispatch being
> > > handled in code. Using mod_setenvif has less overhead.
>
> > > Next thing that can be done is not to use daemon mode of mod_wsgi but
> > > run both instances in embedded mode instead, in separate interpreters.
> > > For this we drop the WSGIDaemonProcess directives. When selecting
> > > based off browser, select application group in embedded mode instead.
> > > Thus:
>
> > > WSGIImportScript /Users/grahamd/Sites/config-1.wsgi \
> > > process-group=%{GLOBAL} application-group=config-1
>
> > > WSGIImportScript /Users/grahamd/Sites/config-2.wsgi \
> > > process-group=%{GLOBAL} application-group=config-2
>
> > > BrowserMatch .* APPLICATION_GROUP=config-2
> > > BrowserMatch Safari APPLICATION_GROUP=config-1
>
> > > WSGIProcessGroup %{GLOBAL}
> > > WSGIApplicationGroup %{ENV:APPLICATION_GROUP}
>
> > > Obviously all the Apache child processes would twice as fat, where as
> > > with daemon mode just one process for each instance.
>
> > > Thus, various ways to handle the dispatch, and also can choose to host
> > > as different interpreters with embedded mode processes or direct to
> > > different daemon mode processes depending on what you need. You could
> > > even get more tricky by running primary instance in embedded mode and
> > > delegating just the one for the special browser to daemon mode,
> > > especially if not frequently used.
>
> > > Anyway, that should give you a lot to chew over. :-)
>
> > > Graham
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
