Hi David,

On Mon, 2006-05-22 at 15:06 -0700, David Elias wrote:
> I think one way to go is with factories.
> The packages don't know nothing where settings coming from. These
> settings are passed within a constructor or something and django would
> use factories that know to look from django.conf.settings and passed
> them to the new object.

That is precisely how it is currently implemented, in effect. Although
it's not a completely plain "factory function", when you first access
django.conf.settings or call configure(), it sets up the right
settings-producing class that is used on all subsequent uses of
django.conf.settings. It's not what a Computer Science student might
immediately identify as a factory function from the shape of the code,
but it is doing the same thing.

And if, for some reason, you wanted to override the settings "producer",
dropping a new implementation of UserSettingsHolder into django.conf is
not too hard either (not documented, since there should be almost no
reason for it and it's not that hard to read the code if you need to).
Something like

        from django import conf
        
        conf.UserSettingsHolder = MyUserSettingsHolder
        conf.settings.configure(...)
        
will work if you do it before anything else accesses the settings.


> Although i don't get it yet, i think dependency injection
> (http://www.martinfowler.com/articles/injection.html) could be a
> possible solution :-)

I'm not entirely sure what you are suggesting here. How does this help
with the usage of this feature (which I assume is what you're talking
about)? At some point, you still have to tell Django what the values for
your particular set of configuration variables are. Or use the defaults.
The configure() function provides that functionality at the moment.

I'm really not sure what pieces you are trying to "decouple" here.
Things like the templating system and ORM need configuration settings.
Some some infrastructure is required. Omitting anything from under
django.conf entirely would not really save lines of code overall. And
the usage API seems about as minimal as you can get (set what you need,
use default for the rest). So can you explain you thinking further?

Malcolm


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~----------~----~----~----~------~----~------~--~---

Reply via email to