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.
On Jan 25, 2016 08:01, "Tim Graham" <timogra...@gmail.com> wrote:

> Oh, looks like django-hosts also has this problem. It looks like in some
> cases the URLs will be correct (due to the PARENT_HOST setting, I think,
> which is 'djangoproject.dev:8000' in the djangoproject.com dev settings),
> but if you are browsing a different host (e.g. the docs site), then those
> URLs use the value from the Site model.
>
> Another thought: 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'},
>     ...
> }
>
> That would solve the portability issue, I think, since you could easily
> override the necessary parts in development settings. Not sure if it'd be
> palatable to deprecation the models though. I don't think maintaining both
> versions would be worthwhile in the long run.
>
> On Monday, January 25, 2016 at 9:57:39 AM UTC-5, Aymeric Augustin wrote:
>>
>> On 25 janv. 2016, at 14:19, Tim Graham <timog...@gmail.com> wrote:
>>
>>
>> I believe it's a common use case to import a copy of a production
>> database and examine it locally -- that's what I meant about portability.
>>
>>
>> I’m not convinced by this argument because the data for the Site model
>> will be wrong anyway in this situation. Or did I miss something?
>>
>> --
>> 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/b12433a7-aa49-4951-9a77-32747699038d%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/b12433a7-aa49-4951-9a77-32747699038d%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> 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/CALfx8k3fZev0ZOfUdKBq-74qSa6qu5n-O7pBTcLz9q7-25Sb%2BQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to