Followed by https://code.djangoproject.com/ticket/27784 I'm gonna revive this discussion about Sites contrib framework.
Let's sum up cases when django.contrib.sites can be used: 1. *Single* django site with totally no use of sites framework. Docs tells us to make a dummy instance anyways... So yeah, It looks like antipattern. +1 for dict settings. 2. *Fixed* django sites that proposed dict in settings would do the job quite easily. +1 for dict settings. 3. *Dynamic* django sites that implements SaaS? Hay, we're now in 2017 It needs not only more fields bound to Site model than domain and verbose name, but can't relate on server restart to reload dict settings. And whose gonna manually change that settings?! -inf for dict settings, +0 model sites. Actually django.contrib.settings needs to be SWAPPABLE. Then it will receive +100. (Oooohh... Someone already proposed this. Even with code sample -> https://code.djangoproject.com/ticket/22779. 3 years ago and ticket still open... How typical... :/) In my project I'm case #2, but I still need a bunch of additional fields to provide for Site. Icons, descriptions, https flags. Think with SaaS and you'll know the drill. Currently making it possible equals ton of hackish lines and definitely more DB queries. Django needs to squish more juice from sites framework. Even for simple uses - Site query is cached anyways. I agree that majority of django powered sites are using SITE_ID = 1, and making dummy instances can be useless overhead, but replacing sites configuration by static dict settings will totally kill the functionality. Sites, when used, should be dynamic and cached. And remember -> sites can be bound dynamically with request.get_host(), so there is no fixed settings (https://github.com/django/django/blob/3c447b108ac70757001171f7a4791f493880bf5b/django/contrib/sites/models.py#L63). W dniu piątek, 29 stycznia 2016 21:45:02 UTC+1 użytkownik Tim Graham napisał: > > In another thread about adding a "scheme" field to the Site model [1], I > floated the idea of moving the data stored by the Site model into a setting: > > I've sometimes thought that the Site model violates the principle that you > shouldn't put configuration in your database. I guess there's some > usefulness to having a ForeignKey to the site, but... would it be feasible > to offer a SITES setting that could be used instead? e.g. > > SITES = { > 1: {'scheme': 'http', 'domain': example.com, 'name': 'My Site'}, > ... > } > > Carl said:+1 to this, I've long felt that the Site model was an > anti-pattern. I don't know if it's worth deprecating and switching to a > different system, though; it'd be a relatively painful deprecation for > those using it, I would guess. > > James said: "In using Marten Kenbeek's URL dispatch rewrite branch, I've > found that using the pattern of defining some site configuration in your > settings is the way to go: it more easily allows you to have URL patterns > on multiple domain/scheme combinations. I use a dict similar to what Tim > has shown, and then use it to initialize my scheme/domain URL constraints > in my root urls.py." > > I'd like to get more feedback and ideas about this. Do you think we'll be > better off in the long run with a setting as opposed to storing the data in > the database? Maybe writing a new sites app that uses a setting instead of > trying to modify the existing models-based one would be a better plan. > > I think the hard problem to solve is what to do about the Redirect and > FlatPage models which have ForeignKey and ManyToManyField relations to the > Site model. > > Perhaps some outcome of this discussion plus considering what features of > related third-party tools like django-hosts [2] might be useful to > incorporate in Django itself would be worthy of a project like Google > Summer of Code. > > [1] > https://groups.google.com/d/topic/django-developers/CzxaPDe8fpI/discussion > [2] https://github.com/jazzband/django-hosts > -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/09f75d9f-7068-4d4f-a926-28dcedf0355b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
