I'm not arguing that the proposal is inherently bad, just that it was
being proposed without understanding the existing solution.
Personally, I use a custom model that inherits from Site to manage my
sites, so it's not like I'm thrilled with the current system either.
I would actually be +0 on adding this as a feature for some future
released, particularly if it was simple, and Site.get_current()-
compatible.
Getting some feedback from the core devs would be great, but they've
definitely got more important things on their minds with the 1.2
deadlines looming. (the ticket list is shrinking fast, though! Keep up
the great work!)
All the best,
- Gabriel
On Mar 13, 5:41 am, Will Hardy <e.willha...@gmail.com> wrote:
> > Does this proposal add any functionality that fixtures do not already
> > provide?
>
> Convenience. It moves the definition of the site away from the
> database, and away from fixtures files and into the settings.
> Personally, I am yet to need multiple sites for a single database, and
> would much prefer being able to set the domain using settings files
> (eg host="localhost:8000" for my settings/local.py on my dev,
> host="production.com.au" for settings/__init__.py etc).
>
> For my needs, being able to define the domain in the settings is much
> more powerful and convenient than storing it in the database and an
> initial_data fixture isn't going to be able to play very cleanly with
> my settings configuration.
>
> Just adding my +1 vote for a standard,
> Site.objects.get_current()-compatible way to set the domain name in
> django.conf.settings. Bonus points if no site table is created and no
> ModelAdmin turns up in admin on auto_discover.
--
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.
