Re: Adding optional SITE_DOMAIN and SITE_NAME variables in settings.py

2010-03-13 Thread aditya
A fixture won't really solve the problem. I'm okay with Gabriel's solution though. It is not as simple as my proposal, but certainly more elegant. Aditya On Mar 13, 6:57 am, Chuck Harmston wrote: > This particular use case (having predefined sets of information loaded

Re: Adding optional SITE_DOMAIN and SITE_NAME variables in settings.py

2010-03-13 Thread Rajeev J Sebastian
On Sat, Mar 13, 2010 at 6:27 PM, Chuck Harmston wrote: > This particular use case (having predefined sets of information loaded into > the database on either syncdb or other command) is what Django's fixture > loading/creation system is for. >

Re: Adding optional SITE_DOMAIN and SITE_NAME variables in settings.py

2010-03-13 Thread Will Hardy
> 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

Re: Adding optional SITE_DOMAIN and SITE_NAME variables in settings.py

2010-03-13 Thread Chuck Harmston
This particular use case (having predefined sets of information loaded into the database on either syncdb or other command) is what Django's fixture loading/creation system is for. http://docs.djangoproject.com/en/dev/ref/django-admin/#what-s-a-fixture

Re: Adding optional SITE_DOMAIN and SITE_NAME variables in settings.py

2010-03-13 Thread Rajeev J Sebastian
On Sat, Mar 13, 2010 at 3:56 PM, Gabriel Hurley wrote: > "domain = Site.objects.get_current().domain" > > The "Site" model in that code comes from the > django.contrib.sites.models, part of the Sites framework I mentioned > above. This is not some bizarre buried database mishap;

Re: Adding optional SITE_DOMAIN and SITE_NAME variables in settings.py

2010-03-13 Thread Gabriel Hurley
"domain = Site.objects.get_current().domain" The "Site" model in that code comes from the django.contrib.sites.models, part of the Sites framework I mentioned above. This is not some bizarre buried database mishap; this is the app developer taking advantage of a contrib app that is included in