我们在中级篇中学会了如何进行反向解析,但是有这样一个问题,在为 url 命名的时候,名字不能重复,否则会导致各种各样的问题。在 url 还少的时候保证不重名还是比较简单的,但是 url 多起来以后就比较难了。为了解决这样的问题,可以在 url 中加一个前缀。例如,我有一个 url 的名字叫做 'comment' ,此时,我可以为其加一个前缀,这个前缀通常是 app 名,例如:'myapp-comment'。
这也是django所推荐的命名方式,但是这样始终是治标不治本。此时,我们就要学习 django 中 url 命名空间了。
URL 命名空间
简介:
URL 命名空间允许你反查到唯一的命名 URL,即使在不同的应用中使用相同的 URL 名称。(也就是可以在不同的app中使用相同的名称,为有命名困难症的程序员带来了福音)
根据经验,第三方应用应该始终使用带命名空间的URL 。类似地,它还允许你在一个应用有多个实例部署的情况下反查URL。换句话讲,因为一个应用的多个实例共享相同的命名URL,命名空间将提供一种区分这些命名 URL 的方法。
在一个站点上,正确使用 URL 命名空间的 Django 应用可以部署多次。例如,django.contrib.admin 具有一个 AdminSite 类,它允许你很容易地部署多个管理站点的实例。在下面的例子中,我们将讨论在两个不同的地方部署教程中的polls 应用,这样我们可以为两种不同的用户(作者和发布者)提供相同的功能。
一个URL 命名空间有两个部分,它们都是字符串:
-
应用命名空间:
它表示正在部署的应用的名称。一个应用的每个实例具有相同的应用命名空间。例如,可以预见Django 的管理站点的应用命名空间是'admin'。
实例命名空间:
它表示应用的一个特定的实例。实例的命名空间在你的全部项目中应该是唯一的。但是,一个实例的命名空间可以和应用的命名空间相同。它用于表示一个应用的默认实例。例如,Django 管理站点实例具有一个默认的实例命名空间'admin'。
URL 的命名空间使用':' 操作符指定。例如,管理站点应用的主页使用'admin:index'。它表示'admin' 的一个命名空间和'index' 的一个命名URL。
命名空间也可以嵌套。命名URL'sports:polls:index' 将在命名空间'polls'中查找'index',而poll 定义在顶层的命名空间'sports' 中。
反查带命名空间的URL
我们在中级篇中了解到了 url 反查带来的变量,而在中级篇中,都是使用 name 进行反查,这里来看看如何对带命名空间的 url 进行反查。
例子:
from django.conf.urls import include, url urlpatterns = [ url(r'^author-polls/', include('polls.urls', namespace='author-polls', app_name='polls')), url(r'^publisher-polls/', include('polls.urls', namespace='publisher-polls', app_name='polls')), ]
from django.conf.urls import url from . import views urlpatterns = [ url(r'^$', views.IndexView.as_view(), name='index'), url(r'^(?P<pk>\d+)/$', views.DetailView.as_view(), name='detail'), ... ]
反查的方法和中级篇的一样,在模板中:
{% url 'polls:index' %}
在基于类的视图的方法中:
reverse('polls:index', current_app=self.request.resolver_match.namespace)
另外,注意,在模板中的反查需要添加 request 的 current_app 属性,像这样:
def render_to_response(self, context, **response_kwargs): self.request.current_app = self.request.resolver_match.namespace return super(DetailView, self).render_to_response(context, **response_kwargs)
这时,会有同学有疑问了, polls 这个应用命名空间设置了两行呀,那 polls 下的 index 到底指的是哪个?
这个时候,就要看 django 的查找顺序了:
1.如果当前有实例,也就是说我们通过 url 访问到了某个处理函数,这个函数进行反向查询的时候,例如我访问的是:author-polls/ ,这个 url 对应的处理函数要进行反向解析,此时它要解析 'polls:detail'。那么将解析到 author-polls/(?P<pk>\d+)/$ 中,也就是有实例的优先在该实例空间中查询。
2.如果没有实例,但是有默认的实例空间,例如 app_name='polls',namespace='polls' ,和应用空间同名,这样的就叫做默认实例空间。在没有访问实例的时候,就匹配到默认实例空间中。
3.如果没有实例,也没有默认实例空间,那么谁是最后注册的就选谁,例子中的 namespace='publisher-polls' 就是最后一个注册的(也就是下面的)。
注意:
因为实例空间要是唯一的,所以使用 namespace:name 的模式应该也是唯一匹配的,例如这里的'author-polls:index' 将永远解析到 'author-polls' 实例的主页('publisher-polls' 类似)。
URL 命名空间和被包含的URLconf
被包含的URLconf 的命名空间可以通过两种方式指定。
首先,在你构造你的URL 模式时,你可以提供 应用 和 实例的命名空间给 include() 作为参数。例如
url(r'^polls/', include('polls.urls', namespace='author-polls', app_name='polls')),
这将包含 polls.urls 中定义的URL 到应用命名空间 'polls'中,其实例命名空间为'author-polls'。
其次,你可以include 一个包含嵌套命名空间数据的对象。如果你include() 一个url() 实例的列表,那么该对象中包含的URL 将添加到全局命名空间。然而,你还可以include() 一个3个元素的元组:
(<list of url() instances>, <application namespace>, <instance namespace>)
注意这里的应用命名空间和实例命名空间是相反的。
实例:
from django.conf.urls import include, url from . import views polls_patterns = [ url(r'^$', views.IndexView.as_view(), name='index'), url(r'^(?P<pk>\d+)/$', views.DetailView.as_view(), name='detail'), ] url(r'^polls/', include((polls_patterns, 'polls', 'author-polls'))),
这样会包含命名的URL模式进入到给定的应用和实例命名空间中。
与 url 相关的函数都在 django.conf.urls 中,下面看看里面都有哪些函数:
1. patterns(prefix, pattern_description, ...)
这是一个废弃了的方法,在 django1.8 之前,urlpatterns 变量是该函数的实例。
例如:
from django.conf.urls import patterns, url urlpatterns = patterns('', url(r'^articles/([0-9]{4})/$', 'news.views.year_archive'), url(r'^articles/([0-9]{4})/([0-9]{2})/$', 'news.views.month_archive'), url(r'^articles/([0-9]{4})/([0-9]{2})/([0-9]+)/$', 'news.views.article_detail'), )
第一个参数是一个前缀,这里的所有表示处理函数的字符串都是以 'new.views' 开头的,所有可以改写成下面这种形式:
from django.conf.urls import patterns, url urlpatterns = patterns('news.views', url(r'^articles/([0-9]{4})/$', 'year_archive'), url(r'^articles/([0-9]{4})/([0-9]{2})/$', 'month_archive'), url(r'^articles/([0-9]{4})/([0-9]{2})/([0-9]+)/$', 'article_detail'), )
因为 patterns 是python的一个方法,而 python 中,一个方法最多接受 255 个参数,也就是说最多可以在一个 patterns 中写 255-1 个 url,虽然这一般不会有什么影响,因为我们可以通过 include 方法来分离 url,而且这个方法返回的是一个列表,所以可以通过列表拼接的方式,来扩展,例如:
urlpatterns = patterns('', ... ) urlpatterns += patterns('', ... )
所以也只是现在最多一次性创建多少个 url 而已。
但是这个方法还是在 1.8 中废弃了(当然你还可强行用,到 1.9.4 为止代码并没有被移除,以后的版本另算),以后直接使用 python 列表,列表中的元素是 url() 函数的实例就行了。而 python 的列表不限制长度,只看电脑的内存有没有足够的空间,所以也算是改进了。
2. static.static(prefix, view=django.views.static.serve, **kwargs)
如果你通过django的后台上传了一张图片,而你又想在前端显示它。一般而言 django 只提供了静态文件的支持(默认是 /static/ 开头的url请求都视为静态文件请求),而图片上传是通过 MEDIA_URL 来作为
请求的开头的,但是如果不做特殊设置,是无法显示的,此时,可以通过以下的方式:
from django.conf import settings from django.conf.urls.static import static urlpatterns = [ # ... the rest of your URLconf goes here ... ] + static(settings.MEDIA_URL, document_root=settings.MEDIA_ROOT)
这是老版本的写法,新版本中直接把函数放进列表中,作为列表中的一个元素就行。
注意:这里我们并没有为 view 传参,直接用默认的就行。
当然,这也只是在开发环境中使用,如果到了正式生产环境,这些东西还是老老实实用 web server ,例如Apache或者nginx之类的作为前方代理,django自带的 web 服务估计并发量在20左右就会挂掉,而且还不是守护进程,也就是说挂掉了不会重启,要多蛋疼有多蛋疼。
3. include(arg, namespace=None, app_name=None)
arg:可以接受一个字符串,表示被包含的模块在哪里;也可以接受一个列表,这个列表是被包含的 url() 的实例;还可以接受一个元祖,元祖的第一个元素是一个被包含的列表,第二个元素是该列表的应用空间名,第三个元素是实例空间名。
namespace : 实例命名空间
app_name : 应用命名空间
4. url(regex, view, kwargs=None, name=None, prefix='')
regex:要匹配的 url。
view:该 url 的处理函数,可以是一个表示函数位置的字符串, 也可以是一个函数的实例。
kwargs: 一个字典,表示传递多余的参数。
name : 为 url 进行命名。
prefix : if prefix: view = prefix + '.' + view 表示在 view 前加上前缀。
5.各种 handler:
django 自带错误处理视图:
handler400 = 'django.views.defaults.bad_request'
handler403 = 'django.views.defaults.permission_denied'
handler404 = 'django.views.defaults.page_not_found'
handler500 = 'django.views.defaults.server_error'
在触发相应的错误的时候,都会转向默认的处理函数,当然我们也可以重写它们,只有在 urls.py 中导入它们,并改写成我们自己的处理函数的字符串表示就可以了。