Django之URL反向解析

一、urls硬编码

在反向解析和命名空间之前我们先来说说URLS硬编码，用django 开发应用的时候，可以完全是在urls.py 中硬编码配置地址,在views.py中HttpResponseRedirect()也是硬编码转向地址，当然在template 中也是一样了，这样带来一个问题，如果在urls.py 中修改了某个页面的地址（也就是说更改路由系统中对应的路由分发），那么所有的地方(views.py和template中)都要修改。问题出在硬编码，紧耦合使得在大量的模板中修改 URLs 成为富有挑战性的项目。来看下面的模板文件index.html中，我们到的链接硬编码成这样子：

如果使用软编码之后，无论怎么更改路由系统中的路由分发，只有对应的namespace与name属性值不变，就不必修改在views.py和template中的url，也就是说

在templates中更改为软编码之后，其实在templates，index.html文件生成的时候，仍然是

二、URL的反向解析

在使用Django 项目时，一个常见的需求是获得URL 的最终形式，以用于嵌入到生成的内容中（视图中和显示给用户的URL等）或者用于处理服务器端的导航（重定向等）。人们强烈希望不要硬编码这些URL（费力、不可扩展且容易产生错误）或者设计一种与URLconf 毫不相关的专门的URL 生成机制，因为这样容易导致一定程度上产生过期的URL。

获取一个URL 最开始想到的信息是处理它视图的标识（例如名字），查找正确的URL 的其它必要的信息有视图参数的类型（位置参数、关键字参数）和值。 Django 提供一个办法是让URL 映射是URL 设计唯一的地方。你填充你的URLconf，然后可以双向使用它： 1、根据用户/浏览器发起的URL 请求，它调用正确的Django 视图，并从URL 中提取它的参数需要的值。 2、根据Django 视图的标识和将要传递给它的参数的值，获取与之关联的URL。

第一种方式是我们常说的根据地址定位URL。

第二种方式叫做反向解析URL、反向URL 匹配、反向URL 查询或者简单的URL 反查。

在需要URL 的地方，对于不同层级，Django 提供不同的工具用于URL 反查： 1、在模板中：使用url 模板标签。2、在Python 代码中：使用 django.core.urlresolvers.reverse() 函数。 3、在更高层的与处理Django 模型实例相关的代码中：使用 get_absolute_url() 方法。

1、命名空间：

URL 命名空间允许你反查到唯一的命名URL 模式，即使不同的应用使用相同的URL 名称。第三方应用始终使用带命名空间的URL 是一个很好的实践。类似地，它还允许你在一个应用有多个实例部署的情况下反查URL。换句话讲，因为一个应用的多个实例共享相同的命名URL，命名空间将提供一种区分这些命名URL 的方法。

一个URL 命名空间有两个部分，它们都是字符串：

<1>、应用命名空间:

它表示正在部署的应用的名称。一个应用的每个实例具有相同的应用命名空间。例如，可以预见Django 的管理站点的应用命名空间是' admin '。

<2>、实例命名空间:

它表示应用的一个特定的实例。实例的命名空间在你的全部项目中应该是唯一的。但是，一个实例的命名空间可以和应用的命名空间相同。它用于表示一个应用的默认实例。例如，Django 管理站点实例具有一个默认的实例命名空间'admin'。 URL的命名空间使用':' 操作符指定。例如，管理站点应用的主页使用' admin:index '。它表示' admin ' 的一个命名空间和' index ' 的一个命名URL.