This is just that I'm doing in django-sites package:
https://github.com/niwinz/django-sites .
+ to have the similar approach in django (sites as settings).
On Fri, Jan 29, 2016 at 10:45 PM, Tim Graham <timogra...@gmail.com> wrote:
> 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/52fee0b1-c08f-4ac5-a01e-34b9baa045ec%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/52fee0b1-c08f-4ac5-a01e-34b9baa045ec%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>
--
Andrey Antukh - Андрей Антух - <n...@niwi.nz>
http://www.niwi.nz
https://github.com/niwinz
--
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/CAOQnsABkw3Ba-i4nC3rxoXqELv4d8ZNhp3h27NtF_KE4xWkvdg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
