Hello...
Modular or divided is not so good as You can feel it now, I think...
For example second web framework I use is symfony. And I hate it
because of this as You say "modularity".
While developing big project I have more then 50 open buffers in emacs
only, plus gvim buffers, plus console windows and console tabs. These
all are on concentrated on 4 desktops.
Q: Do I need 10 or more configuration files in addition to these?
On May 28, 2:19 am, "burc...@gmail.com" wrote:
> Hi everybody,
>
> Everyone loves the way templates are discovered in django.
> No one loves settings.py that much.
>
> This is proposal on how to improve situation significantly.
>
> Configuration facility is suggested in addition to django.conf.settings.
> Configuration is going to be put into conf/ directory of the project
> (or settings/ -- just set config.global.CONFIG).
>
> :: settings.py ::
> from django.conf import config
> from os.path import dirname, abspath, join
> ROOT = dirname(abspath(__name__)) # type 'str'
> INSTALLED_APPS = ...
>
> config.global.ROOT = ROOT
> config.global.CONFIG = join(ROOT, 'conf')
> config.autodiscover()
> # config.global is in fact a synonym for settings
>
> :: conf/global.py ::
> # runs before the app settings
> from django.conf import config
> from os.path import dirname, abspath
> ROOT = config.global.ROOT # type 'str', empty if not set.
> config.global.JQUERY.default = JQUERY = ROOT +
> 'static/js/jquery-1.3.2-min.js' # type 'dict', setting default value
> for missing items
> config.global.JQUERY['1.3.2'] = JQUERY # type 'unordered dict with
> default value', now setting arbitrary key
> config.global.MEDIA += [ROOT + 'static/js/'] # type 'ordered set with
> default value'
> config.global.DATABASES['default'] = {...} # backward-compatibility,
> so using 'default' not .default!
> # Note: after type is set for constant, the type can't be changed.
> # Note: please set to tuple not list if you need a clear sign the
> option won't be additive any more.
>
> :: conf/global_overrides.py ::
> # runs after all other settings but before _overrides, see below
> # is now empty
>
> :: conf/apps/myapp.py ::
> # runs after all app-specific settings
> app.DATABASES['db3'] = {...}
> app.ROUTERS += ['Db3_is_readonly']
>
> :: conf/www_server_com.py
> # runs before app-specific settings
> from django.conf import config
> config.global.MEDIA_ROOT = '/var/site/www.server.com/site_media/'
> config.global.MEDIA_URL = 'media.server.com'
> app.MIDDLEWARE += ['caching.smart_caching_app.SmartCacher']
>
> :: conf/www_server_com_overrides.py
> # runs after app-specific settings
> config.global.JQUERY['1.3.2'] = 'static/packed.js'
> config.global.JQUERY['1.4.2'] = 'static/packed.js'
>
> :: myapp/conf.py ::
> # runs in order specified in INSTALLED_APPS
> from django.conf import config
> app = config.apps.myapp
> app.DEPENDS += ['django.contrib.auth']
> app.STATIC = app.global.ROOT + 'media/myapp/'
> app.IMAGES = app.global.ROOT + 'media/uploads/images/'
> app.THUMBS = app.global.ROOT + 'media/uploads/thumbs/'
> config.global.MEDIA += [app.IMAGES, app.THUMBS, app.JSES, app.CSSES]
> config.global.JQUERY['1.4.2'] = STATIC + 'js/'
> config.global.TAGS += ['app1.templatetags.mytags']
>
> :: myapp/forms.py ::
> from django.conf import config
>
> app = config.apps['myapp']
> class MyForm:
> class Media:
> css = app.STATIC + 'css/base.css'
> js = config.global.JQUERY['1.4.2']
>
> The ultimate order:
>
> django/conf/global.py
> conf/__init__.py
> conf/global.py # -- you can also set your own personal order there
> conf/.py
> app1/conf.py # -- single pass is enough, cause applications can both
> provide callbacks for later configuration stages.
> app2/conf.py
> ...
> appN/conf.py
> conf/apps/app1.py
> conf/apps/app2.py
> conf/apps/appN.py
> conf/global_overrides.py
> conf/_overrides.py
>
> * forwww.my-site.comis www_my__site_com (dots replaced with
> underlines, dash with double underline).
> socket.getfqdn() is used for determining current site.
>
> The motivation is simple:
> the bigger your list of application grows, the larger configuration
> you will have!
> Django has more than 100 of different settings options.
> They are not even grouped now.
> I hope such django "built-in" type of configuration will suit 99% of
> the possible Django projects, and will make django community much
> stronger.
>
> I'm going to create a prototype.
>
> Expected benefits:
> - 3rd-party applications can be used without a bit of touching and
> still customized perfectly.
> - Application can connect to each other in dynamic way, or provide
> different kinds of plugin points.
> - Fixed models dependencies can be replaced with dynamic (i.e, each
> application might ask for personal User or UserProfile replacement)
> - Really simple media setup for both development and production servers.
> - A number of development and production configurations can coexist
> in the project, without single 'if'
> - Per-application configuration
