On Thu, Sep 4, 2014 at 4:39 PM, Carl Meyer <[email protected]> wrote: > On 09/04/2014 05:36 PM, Collin Anderson wrote: > > I'm trying to think outside the box on settings. > > > > If we want to logically group settings together, what if we supported > > syntax like this? > > > > MIDDLEWARE_CLASSES = ( > > 'django.middleware.clickjacking.XFrameOptionsMiddleware', > > SecurityMiddleware(content_type_nosniff=True, xss_filter=True), > > ) > > > > It could be a more pythonic way for middleware to have their own > settings. > > Proposals like this generally run afoul of circular import problems. As > soon as you have people importing parts of Django or their project in > their settings file, those modules likely import other modules which in > turn import django.conf.settings, and boom! >
Since I'm sitting at the DjangoCon US sprints, and I'm feeling a little optimistic and crazy, I thought I'd throw this idea out there... The other way to resolve this would be to rethink the way Django starts up. Settings like MIDDLEWARE_CLASSES have always struck me as being a little odd - they're not really settings, they're a way to configure the way code is executed without actually writing and executing code. The same is true of things like ROOT_URLCONF, a few of the template loaders and path specifications, and so on. If we were starting green-fields, it seems to me that we wouldn't do it this way; the Pyramid/Flask approach of doing this sort of thing by actually defining code would make a lot more sense. Django currently has a well defined, but opaque startup sequence where settings are loaded and then the middlware, urlconfs etc are set up. The alternative would be an explicit startup sequence that constructs the desired middlewares, installs them into a root urlconf, configures loaders and so on, and then sets the environment running. This should also avoids the circular dependency problem, because anything that needs to do an import in the settings file would be part of the configuration process. To be clear, I know this would be a huge change. If we went down this path, we'd need to maintain the old/current way of deploying Django for a long time. In the interests of getting started quickly, it might even be desirable to maintain both approaches long term. But having an explicit startup sequence would allow for complex middleware configuration like this thread has proposed. I'm just throwing this idea out on the porch to see if the cat licks it up. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAJxq84_P%3D3_Wi8DLwav7qtiw5C249TEwAeLrJJnx4VXEkanNrg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
