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

-1. The only issue that I have with sites is that the default site should be 127.0.0.1:8000 since that's what runserver defaults to. Putting example.com as SITE_ID 1 only makes novice django developers shout and throw things because like me they 'add 127.0.0.1:8000 and delete example.com' instead

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

About idea of use settings.py to set a default site, -1 About ask to user what is yours default site, +1 This thing only runs at syncdb, so I really don't think that a entry in settings.py is needed. 2010/5/18 Oldřich Jedlička > Hi, > > 2010/3/19 dalore

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

Hi, 2010/3/19 dalore > Because of this thread I decided to release a little app we have been > using internally. It's a straightforward way to modify the default > site object. > > More details: http://oppian.com/labs/django-defaultsite/ > > Any comments/suggestions welcome.

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

Because of this thread I decided to release a little app we have been using internally. It's a straightforward way to modify the default site object. More details: http://oppian.com/labs/django-defaultsite/ Any comments/suggestions welcome. Sincerely Matthew Jacobi Oppian Systems Ltd On Mar

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

On Mar 15, 10:44 am, Yuri Baburov wrote: > Hello all, > > How do you like the following idea: > startproject command puts a fixture for django.contrib.sites (and > fixture for superuser probably) to the root folder or whatever, to be > loaded with syncdb? > That way also

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

There is a ticket for something similar #8896 (http://code.djangoproject.com/ticket/8896). Let urlresolvers also route according to hostname. -- Gert Mobile: +32 498725202 Web: http://gert.selentic.net 2010/3/15 jens : > On Mar 15, 3:44 pm, Yuri Baburov

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

On Mar 15, 3:44 pm, Yuri Baburov wrote: > How do you like the following idea: > startproject command puts a fixture for django.contrib.sites (and > fixture for superuser probably) to the root folder or whatever, to be > loaded with syncdb? IMHO it would be a great, if django

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

Hello all, How do you like the following idea: startproject command puts a fixture for django.contrib.sites (and fixture for superuser probably) to the root folder or whatever, to be loaded with syncdb? That way also encourage users to get more familiar with fixtures. Of course it's too far for

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

Le 14 mars 2010 à 12:27, James Bennett a écrit : > On Fri, Mar 12, 2010 at 4:39 PM, aditya wrote: > >> 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. > 2. If it turns out

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

I guess at some point its just feature-clut. Its a use case we _could_ encompass, but would you really even find yourself using it? I don't see the technical difference here--pre-syncdb, you either have to 'wade' to the database or you have to 'wade' to this item in settings.py. Its not as though

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

Fair enough. As Gabriel pointed out earlier, I didn't realize that I could change those values by adding django.contrib.sites to my INSTALLED_APPS. That's why I said there was no straightforward way of configuring those values. I wish Django had some sort of 'sample proposals' on their site. You

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

On Fri, Mar 12, 2010 at 4:39 PM, aditya 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

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

On Sun, Mar 14, 2010 at 12:58 PM, Gabriel Hurley wrote: > 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

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

On Sun, Mar 14, 2010 at 12:58 PM, Gabriel Hurley wrote: > I'm not arguing that the proposal is inherently bad, just that it was > being proposed without understanding the existing solution. That's not what I got from your harsh responses. The existing "solution" is to modify

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

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

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

> 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

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

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

"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

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

Could you be more specific? I'm not sure what you mean. Aditya On Mar 12, 5:26 pm, Gabriel Hurley wrote: > You seem to be missing the point of the code you reference above. You > should probably read up on the "Sites" framework that ships with > Django: > >

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

You seem to be missing the point of the code you reference above. You should probably read up on the "Sites" framework that ships with Django: http://docs.djangoproject.com/en/dev/ref/contrib/sites/ All the best, - Gabriel On Mar 12, 1:39 pm, aditya wrote: >

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

On Sat, Mar 13, 2010 at 3:09 AM, aditya wrote: > Description > = > This page of the Django documentation shows how to use the 'Sites' > framework to get the domain of the current site: > > http://docs.djangoproject.com/en/dev/ref/contrib/sites/ > > I've noticed

[Proposal] Adding optional SITE_DOMAIN and SITE_NAME variables in settings.py

Description = This page of the Django documentation shows how to use the 'Sites' framework to get the domain of the current site: http://docs.djangoproject.com/en/dev/ref/contrib/sites/ I've noticed that 'domain = Site.objects.get_current().domain' is becoming a common idiom in Django.