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" <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 <site>_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/<site*>.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/<site*>_overrides.py
>
> *<site> 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 for middlewares, databases, routers,
> context processors and other "additive" options
>  - Preconditions for visual application settings (Needs another proposal)
>  - Django core settings will be moved to namespaces and grouped semantically.
>  - Sparse config is better than dense.
>
> Why it needs to be in the django core, not just 3rd-party plugin:
>  - Because "Namespaces are one honking great idea -- let's do more of those!"
>  - Because config ubiquity between projects is the main project benefit.
>
> --
> Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov,
> MSN: bu...@live.com

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Reply via email to