[Pony] Per app settings
shabda.raaj
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.
This is sort of influenced by how apache allows distributed
configuration using httpd.conf for per server settings, and .htaccess
for distributed configuration. We can proabably get an idea or two
from there.
I was doing a little research and saw #5049, which was closed as
WONTFIX by Russell, but I cant seem to find the referenced discussion,
and am posting this as maybe this proposal is significantly different
than what was discussed in the past. :)
Waylan Limberg
>
> I was doing a little research and saw #5049, which was closed as
> WONTFIX by Russell, but I cant seem to find the referenced discussion,
> and am posting this as maybe this proposal is significantly different
> than what was discussed in the past. :)
My understanding is that any app specific stuff is to come under the
planned INSTALLED_APPS refactor in #3591. There are also some notes on
the wiki[1]. Personally, I have no idea if the plan includes a way for
app specific settings files or not, so this may or may not address
your pony.
In any event, I seem to recall is being pointed out before that the
settings file is just python code. There is noting stopping you from
importing other app specific settings files into settings.py.
Presumably, you would want to do such an import at the end of the file
so as to override the project defaults.
Although, rereading your request, that wouldn't do what you want. The
thing is, settings are loaded once at server init and remain unchanged
across requests. However, you want settings to change for each request
depending on which app a view resides in. That's determined in url
resolution. Remember a url.py file in one app could point to a view in
another app. Perhaps a wrapper (or decorator) around your views could
add the appropriate context. Settings are global and constant, they're
not the place for this sort of thing.
[1]: http://code.djangoproject.com/wiki/InstalledAppsRevision
--
----
Waylan Limberg
way...@gmail.com
Malcolm Tredinnick
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