On Fri, Mar 12, 2010 at 4:39 PM, aditya <bluemangrou...@gmail.com> wrote: > The trouble is, there is no straightforward way to configure the name > and domain of a site.
Sure there is: create a Site object, or edit an existing one, setting the values you want on it. > Currently, Django uses "example.com" for both the domain and the > name. The only way to change that is to wade into the actual > database. You say this as if it's something obviously evil and horrible and terrible, but provide no explanation of *why* it's bad. You then propose solving this problem by adding two new settings to Django which will be used only when syncdb installs the sites app and then never referenced ever again. If you want this proposal to be taken seriously, you'll need to: 1. Explain why you think it's such a bad thing for a framework which offers easy ways to interact with your database to... ask you to interact with your database. 2. If it turns out there's a real problem, provide a solution which doesn't involve one-time settings and which, preferably, leverages existing and proven features of Django rather than trying to add new ones just for this case. Admittedly these will be rather high hurdles, since I don't honestly see what the problem is here; yes, you'll end up editing the default Site object, but there are things which need a Site object to exist as soon as contrib.sites is installed, and so we just default to the safest possible thing: the example domain name reserved for this sort of use by RFC2606. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." -- 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.
