Re: Replacing the contrib.sites Site model with a setting?

2017-02-19 Thread Wim Feijen 
Hi all,

I'm in favour of defining the sites in settings. In addition, it would ease 
transferring db dumps from live to test servers and it would prevent db 
queries.

I wonder, because we define sites in ALLOWED_HOSTS as well, whether we can 
combine these settings. 

For scheme, what are expected values here? As we are moving from http to 
https environments, I wonder: do we still want to define schemes? I prefer 
following server configuration here.

Wim


-- 
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/bdde6046-1e4a-40c2-b772-436e9c7ddc82%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Replacing the contrib.sites Site model with a setting?

2017-02-04 Thread Robert Singer 
I don't think its feasible to move away from db model entirely. Widely used 
packages like django CMS rely on there being a site model. 

On Friday, January 29, 2016 at 2:45:02 PM UTC-6, Tim Graham 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/af8e6f75-8b0b-4169-9b2c-313908a59f8b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Replacing the contrib.sites Site model with a setting?

2017-01-30 Thread Shai Berger 
On Sunday 29 January 2017 22:54:12 Proxy wrote:
> 
> 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.
> 

In that case, and until Site becomes swappable, you should be able to do what 
we all did before User was swappable: Define a "SiteProfile" model, with a 1-1 
relationship to Site, where you can add fields to your heart's content.

> Currently making it possible equals ton of hackish lines and definitely
> more DB queries.
> 

So, could you explain why that is the case?

Shai.

Re: Replacing the contrib.sites Site model with a setting?

2017-01-30 Thread Scot Hacker 
+1 for this change. 

This issue bites our team every time we copy a db from production to dev or 
stage or local, and certain features break because of the mis-pointed Sites 
setting.  

./s

-- 
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/903506e5-5b77-4e19-a028-3e714927b14e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Replacing the contrib.sites Site model with a setting?

2017-01-29 Thread Proxy 
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.

Re: Replacing the contrib.sites Site model with a setting?

2016-02-03 Thread Tim Baxter 
What would be the recommendation for assigning content to a particular site 
in a shared DB model? Integer field with the current SITE_ID to create a 
sort of faux FK or M2M? Choices?

One thing I like about this pattern I haven't seen discussed already is 
that it would make it far easier to extend Sites as need. For example, one 
request I've had is the ability to store some additional information on 
Sites beyond name and domain. This would provide a pretty straightforward 
mechanism to do so.

-- 
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/53b7ac67-f4c5-4f4a-b175-a3df9172a39c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Replacing the contrib.sites Site model with a setting?

2016-02-02 Thread Anssi Kääriäinen 
Could we make the sites portion of Django an interface? In settings you 
give something like SITES_PROVIDER = 'myapp.sites.MultiTenancySite', and 
that provider then needs to fulfill a given API. This way we wouldn't need 
to offer anything complex in-built, but users would be free to do whatever 
they want to.

 - Anssi

On Saturday, January 30, 2016 at 11:11:08 AM UTC+2, Aymeric Augustin wrote:
>
> This is a valid use case, but not one django.contrib.sites (officially) 
> supports, since it requires a constant SITE_ID setting. 
>
> While Tim's suggestion doesn't cause a regression, it doesn't make this 
> pattern easier to implement either. 
>
> It's definitely worth considering. 
>
> -- 
> Aymeric. 
>
> > Le 30 janv. 2016 à 08:01, Max Arnold  a 
> écrit : 
> > 
> > What if this list of sites needs to be changed dynamically without app 
> restart (multitenancy)? 
> > 
> >> On Fri, Jan 29, 2016 at 12:45:02PM -0800, Tim Graham 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'}, 
> >>... 
> >> } 
> > 
> > -- 
> > 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-develop...@googlegroups.com . 
> > To post to this group, send email to django-d...@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/20160130070141.GA2770%40otg.dm.
>  
>
> > For more options, visit https://groups.google.com/d/optout. 
>

-- 
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/2014647b-aa3d-412f-8fc3-a0bc646e9a4e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Replacing the contrib.sites Site model with a setting?

2016-01-30 Thread Aymeric Augustin 
This is a valid use case, but not one django.contrib.sites (officially) 
supports, since it requires a constant SITE_ID setting.

While Tim's suggestion doesn't cause a regression, it doesn't make this pattern 
easier to implement either.

It's definitely worth considering.

-- 
Aymeric.

> Le 30 janv. 2016 à 08:01, Max Arnold  a écrit :
> 
> What if this list of sites needs to be changed dynamically without app 
> restart (multitenancy)?
> 
>> On Fri, Jan 29, 2016 at 12:45:02PM -0800, Tim Graham 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'},
>>...
>> }
> 
> -- 
> 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/20160130070141.GA2770%40otg.dm.
> For more options, visit https://groups.google.com/d/optout.

-- 
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/BD11589E-99B7-4D14-9F60-5D346D557B98%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.

Re: Replacing the contrib.sites Site model with a setting?

2016-01-29 Thread Max Arnold 
What if this list of sites needs to be changed dynamically without app restart 
(multitenancy)?

On Fri, Jan 29, 2016 at 12:45:02PM -0800, Tim Graham 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'},
> ...
> }

-- 
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/20160130070141.GA2770%40otg.dm.
For more options, visit https://groups.google.com/d/optout.

Re: Replacing the contrib.sites Site model with a setting?

2016-01-29 Thread Andrey Antukh 
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  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
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Andrey Antukh - Андрей Антух - 
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.

Re: Replacing the contrib.sites Site model with a setting?

2016-01-29 Thread Aymeric Augustin 
> On 29 janv. 2016, at 21:45, Tim Graham  wrote:
> 
> Do you think we'll be better off in the long run with a setting as opposed to 
> storing the data in the database?

Yes.

-- 
Aymeric.

-- 
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/FB136E5B-3C4D-4699-9E6C-02FDABCAE968%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.

Re: Replacing the contrib.sites Site model with a setting?

2016-01-29 Thread Chris Foresman 
+1 on setting. That's what I've ended up doing on all of my projects 
anyhowways. 

On Friday, January 29, 2016 at 2:45:02 PM UTC-6, Tim Graham 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/ef25366e-e1b4-4f35-ad6c-c5974fd359e1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Replacing the contrib.sites Site model with a setting?

2016-01-29 Thread Tim Graham 
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.
For more options, visit https://groups.google.com/d/optout.