Malcolm Tredinnick wrote:
> 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?
Hi there,
I was thinking in way to remove lines like this
from django.conf import settings
from the template system and ORM, something like passing the desireable
settings within the constructor, or something. About the factories i
was not mention the one of django.conf, i was thinking in factories
that belongs to django and not to the template system or ORM.
Right now i don't have some code to demonstrate, i'm also writing a
firebird backend so i'm learning how the frameworks works as well.
>
> 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
-~----------~----~----~----~------~----~------~--~---
