Prawdziwy przykład przestrzeni nazw URL

Zazwyczaj są one używane do umieszczania adresów URL każdej aplikacji w ich własnej przestrzeni nazw. Dzięki temu funkcja Django

reverse ()

i funkcja szablonu

{% url%}

nie zwracają nieprawidłowego adresu URL, ponieważ nazwa szablonu adresu URL została przypadkowo dopasowana w innej aplikacji.
To, co mam w pliku

urls.py

na poziomie projektu, to:

from django.conf.urls.defaults import *

from django.conf import settings

from django.contrib import admin

admin.autodiscover()urlpatterns = patterns('',

 url(r'^$', 'main.views.main', name='main'),

 url(r'^login$', 'django.contrib.auth.views.login', name="login"),

 url(r'^logout$', 'django.contrib.auth.views.logout',

 {"next_page": "/"}, name="logout"),# Admin

 url(r'^admin/doc/', include('django.contrib.admindocs.urls')),

 url(r'^admin/', include(admin.site.urls)),)# Auto-add the applications.

for app in settings.LOCAL_APPS:

 urlpatterns += patterns('',

 url(r'^{0}/'.format(app), include(app + '.urls', namespace=app)),

 )

Zwróć uwagę na ostatnią sekcję: przechodzi przez aplikacje, które zainstalowałem (

settings.LOCAL_APPS

to ustawienie, które dodałem, które zawiera tylko moje aplikacje; jest dodawane do

INSTALLED_APPS

, które ma inne rzeczy takie jak South) wyszukuje

urls.py

w każdym z nich i importuje te adresy URL do przestrzeni nazw nazwanej na cześć aplikacji, a także umieszcza te adresy URL w podkatalogu URL nazwanym na cześć aplikacji.
Na przykład, jeśli mam aplikację o nazwie

hosts

i

hosts/urls.py

wygląda tak:

from django.conf.urls.defaults import *urlpatterns = patterns('hosts.views',

 url(r'^$', 'show_hosts', name='list'),)

Teraz mój

views.py

może wywołać

reverse („hosts: list”)

, aby uzyskać adres URL strony, która wywołuje

hosts.views.show_hosts

i będzie wyglądać jak

"/ hosts/"

. To samo dotyczy

{% url "hosts: list"%}

w szablonie. W ten sposób nie muszę się martwić o kolizję z adresem URL o nazwie „lista” w innej aplikacji i nie muszę poprzedzać każdej nazwy przedrostkiem

hosts_

.
Zauważ, że strona logowania znajduje się pod adresem

{% url "login"%}

, ponieważ nie otrzymała przestrzeni nazw.

Pomyśl, że używasz wzorca adresu URL, jak poniżej

url(r'^login/',include('app_name', name='login'))

Weź również pod uwagę, że używasz aplikacji innej firmy, takiej jak Django-RestFramework.
Korzystając z aplikacji, należy zadeklarować następujący wiersz w pliku konfiguracyjnym adresów URL projektu.

url(r'^api-auth/', include('rest_framework.urls', namespace='rest_framework'))

Teraz, jeśli sprawdzisz kod reszty struktury, znajdziesz następujący kod w pliku urls.py

urlpatterns = [

 url(r'^login/$', login, login_kwargs, name='login'),

 url(r'^logout/$', logout, name='logout'),

]

Użyliśmy nazwy „login” jako wzorca adresu URL w naszym projekcie i ta sama nazwa jest używana przez framework Django-rest dla jednego z ich wzorców URL. Kiedy używasz reverse ('login'), Django jest zdezorientowany.

Używamy przestrzeni nazw do rozwiązywania tego rodzaju problemów.

@register.simple_tag

def optional_docs_login(request):

 """

 Include a login snippet if REST framework's login view is in the URLconf.

 """

 try:

 login_url = reverse('rest_framework:login')

 except NoReverseMatch:

 return 'log in'

Nazwy przestrzeni nazw URL Nigdy nie kolidują z innymi przestrzeniami nazw.

Wzorzec adresu URL w przestrzeni nazw można odwrócić za pomocą

reverse('namespace:url_name')

Przestrzeń nazw używamy również w oprogramowaniu pośrednim, aby obsługiwać niektóre z nich w inny sposób

def process_response(self, request, response):

 try:

 if resolve(request.path).namespace == 'special_namespace':

 response['Custom-Header'] = 'Custom-Value'

 return response

 except Resolver404:

 return response