Hi Django developers, This is my first message here. I wish to resurrect Application (default) settings modules -- a topic that has been discussed here several times. I bring it up because I believe its current resolution is inadequate (hence it keeps coming up) and I think I have a new way to solve it. I have detailed it in a comment on the bug (http://code.djangoproject.com/ticket/1371#comment:8 -- where I also stepped out of line and reopened it, for which I apologize); I repeat it here (slightly edited) for your convenience.
Quoting myself: ...[T]he main objection to this feature is that it lets apps include their own settings in the global settings object, and I tend to agree with that sentiment. However, I still think it is much nicer for the application settings to be concentrated in one place. This would help not only deployers, but also developers who will be able to rely on IDE services (intellisense, refactoring) for their own settings. My idea for not messing with the global settings object, is for each app to have its own settings object, which serves as a proxy to the global settings object. The global settings object remains un-tainted. With the appsettings module [http://code.djangoproject.com/attachment/ticket/1371/appsettings.py], the application would include a conf.py file looking like so: """ import appsettings as appset class Settings(appset.AppSettings): # A setting with a default given directly MY_SETTING = 17 # A setting which defaults to some other setting MY_SETTING_FROM_OTHER = appset.FromSetting('ROOT_URLCONF') # Defaults can use settings from this file, too MY_SETTING_FROM_LOCAL = appset.FromSetting('MY_SETTING') # Defaults can be computed, and not just copied from other settings MY_SETTING_WITH_COMPUTED_DEFAULT = appset.ComputedSetting(lambda x,y,z=0:x*y+z, ['MY_SETTING'], 3, z=17) # This must be set in the settings module MY_TOP_SETTING = appset.RequiredSetting() settings = Settings() """ And the app should then just replace its "from django.conf import settings" with "from myapp.conf import settings". This addresses all concerns raised before, that I am aware of: * Applications cannot touch each-other's defaults (unless some app explicitly imports another's settings) * Required settings can be clearly marked as such o When so marked, if not defined in the settings module, their use in the code will predictably raise ImproperlyConfigured, instead of each app raising its own error * No registration required * No backwards compatibility issues, just a way to make things better in the future * No default clashes even if name clashes occur (each app can have its own default for the same name) -- so the setting-name-clash situation is not worsened. * No more RY "if hasattr(settings,'...')". Just use the setting value in your code. * The FromSetting and ComputedSetting classes are further RY-removing convenience features End quote. Actually, since posting the comment, I realized two things: * app-specific settings objects whose classes inherit from a common class can help solve issues of configuration modularization (e.g. one of the earlier posters on the bug mentioned allowing apps with the same name) * Not sure if this supports or detracts from the suggestion, but there are more default-helper classes (such as FromSetting and ComputedSetting above) to define -- in my own project, I just added FirstOf (takes a list of default values, including helper objects, and sets the parameter to the first value available). There are probably more interesting possibilities, and there is probably some risk of bloat. Thanks for your attention, Shai. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
