On Thu, 2008-10-23 at 10:29 -0700, shabda.raaj wrote: > My project is, > > project/ > blog/ > forum/ > wiki/ > setting.py > > Now so all my views from blog/ must have the Blog object, all views > from forum should have Forum object, all views from wiki should have > Wiki object. > > So in settings.py I can have > > TEMPLATE_CONTEXT_PROCESSORS = ( > 'wiki_contextprocessor', > 'blog_contextprocessor', > 'forum_contextprocessor' > ) > > And maybe similarly for MIDDLEWARE. > > However this means that each middleware and context processor get used > even when they should not be, with extra DB hits. > > So my pony request is, > > 1. Each app can have an app_settings.py. > 2. This app_settings.py ADDS to the the settings, where settings are > tuples, or OVERRIDES in other cases. > 3. The app_settings.py comes into play only when the view from that > app is executed.
Strong -1 from me, for all the reasons that have been raised in the past about this: lots of applications depend upon other applications already being installed, which means there's going to be some ordering constraints that will be very easy to get wrong for app-specific settings. Asking people installing an application to do the configuration in one place, rather than being able to close their eyes and hope the application does it, provides a sensible place to serialise all the interactions. It is entirely up to the application user to set up the settings properly. To get an idea of the types of problems that might arise, imagine an application that wants to put its template directories first so that it overrides templates for something else. Now have two such applications. Instant problem; which one wins depends on installation order. And you won't notice this because it's hidden inside the application. The current system, where the user of those applications has to set up the template directories, reveals the problem immediately, because the installation instructions for the two applications cannot be completed properly. Overrides vs. adds is simply a matter of assignment or not. There shouldn't be anything special about tuples or lists or anything else. Normal Python behaviour should apply: if you assign a new value to a variable, it changes. Point 3 doesn't seem to be solving any particular problem. Applications are loaded long before their views are executed, as a general rule. Holding off on parts of that (for reasons that unclear in your proposal) would add extra complexity. Why is this at all necessary? Settings are fundamentally static things that are set up and then left alone, so it shouldn't matter when they are loaded. Regards, Malcolm --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
