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 <ch...@chuckharmston.com> 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. > > http://docs.djangoproject.com/en/dev/ref/django-admin/#what-s-a-fixturehttp://docs.djangoproject.com/en/dev/howto/initial-data/#providing-in... > > Does this proposal add any functionality that fixtures do not already > provide? > > Best, > Chuck > > On Sat, Mar 13, 2010 at 5:50 AM, Rajeev J Sebastian < > > rajeev.sebast...@gmail.com> wrote: > > On Sat, Mar 13, 2010 at 3:56 PM, Gabriel Hurley <gab...@gmail.com> 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; this is the > > > app developer taking advantage of a contrib app that is included in > > > Django. > > > > You complain "The trouble is, there is no straightforward way to > > > configure the name and domain of a site" but if you actually *include* > > > django.contrib.sites in your INSTALLED_APPS you'd see that it's EASILY > > > configurable using the Django admin, and that it in fact offers you > > > some very useful features if you want to publish similar content on > > > multiple domains. > > > > As of Django's 1.0 release the Sites framework is supported as an > > > *optional* component, allowing developers to take advantage of it in > > > their apps without requiring that everyone use contrib.sites. This is > > > accomplished using the RequestSite object. You can read about that > > > here: > > >http://docs.djangoproject.com/en/dev/ref/contrib/sites/#requestsite-o... > > > > However, if you're in the habit of using 3rd-party apps that take > > > advantage of the Sites framework, I strongly suggest you simply *add* > > > "django.contrib.sites" to your INSTALLED_APPS in settings. Then you > > > can edit it via the Django admin, the Django shell, or by whatever > > > method you choose. > > > > Adding another setting in place of the actual contrib.sites app would > > > be a *different* solution to the problem solved by RequestSite, but I > > > don't see that it offers any real advantages. > > > > Please read the docs I linked you to carefully. It really does explain > > > everything you need to know to understand why your proposal is off- > > > base. Again: > > > Gabriel, > > > I think, you haven't read the proposal correctly. > > > The suggestion was that, syncdb for e.g., would create the default > > Site using the settings SITE_DOMAIN and SITE_NAME instead of blindly > > using 'example.com'. > > > This prevents the need to go in an edit the domain within the admin > > (or run some python code in shell) everytime one does a syncdb. It is, > > quite simply, a suggestion to allow overriding the django default when > > creating the *default* Site object. > > > Regards > > Rajeev J Sebastian > > > -- > > 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<django-developers%2bunsubscr...@googlegroups.com> > > . > > For more options, visit this group at > >http://groups.google.com/group/django-developers?hl=en. -- 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.
