django 1.3 url 模板标签和基于类的视图答案

【问题标题】：django 1.3 url template tag and class-based viewsdjango 1.3 url 模板标签和基于类的视图
【发布时间】：2012-03-11 10:09:58
【问题描述】：

我刚刚开始将我必须从 1.1 迁移到 1.3 的应用程序。

我开始深入了解基于类的观点并被震撼了，但不是很好。
我有一些抱怨，但这里的具体问题是：

这是我可以将 url 模板标签与基于类的通用视图一起使用的唯一方法吗？
Django reverse url with parameters to a class based view
即必须命名每一个 url 条目？

这对我来说似乎很荒谬，因为 Django 的基本哲学之一是 DRY，但我们在这里.... RY-ing.....

提前致谢。

编辑：
所以我有https://gist.github.com/1877374

并得到错误模板语法错误渲染时捕获 NoReverseMatch：“views.HomeView.as_view”的反向参数“()”和关键字参数“{}”未找到。

我是不是用错了？

切线：
如果我们必须在 urls.py 文件中命名每一个条目

，我想进一步解释一下为什么我认为我们在 RY-ing

我的 urls.py 通常看起来像 https://gist.github.com/1877462

我完全了解解耦。
这里的重点是我们有能力在需要时这样做。当我需要时，我绝对会使用名称功能。否则，我为什么要花时间和精力为每个条目添加 url 并为每个条目命名，而它们通常与views.py 中的类/函数的名称相同？

也许这应该分成一个关于 SO 的单独问题。

【问题讨论】：

【解决方案1】：

这里有一个相当直接的解释，说明为什么不命名就不能反转基于类的视图。我对 Django 内部结构不是很熟悉，所以很高兴得到纠正。

使用基于函数的视图，

# my_app.views.py
def my_view(request):
    return HttpResponse("Hello, world!")

你可以反转my_app.views.my_view，因为它是一个可调用视图函数的路径。

使用基于类的视图，

# my_app.views.py
class MyView(TemplateView):
    template_name = "hello_world.html"

你不能反转my_app.views.MyView，因为它不是一个可调用的视图对象。可调用视图是MyView.as_view()。如果您将MyView.as_view() 分配给视图中的变量，如下所示：

# my_app.views.py
class MyView(TemplateView):
    template_name = "hello_world.html"
my_view = MyView.as_view()

# urls.py
url('^$', `my_view`),

那么您将能够在不命名my_view 的情况下对其进行反转。此选项与命名您的网址一样重复，所以我认为您不会喜欢它！。

但是，当您将 MyView.as_view() 直接放在您的 url 模式中时，它是一个匿名函数。它尚未分配给任何变量，因此没有可用于反转它的路径。同样，您将无法撤消以下操作：

url('^$', lambda request: HttpResponse("Hello, World!")),

请注意，url() 基本上只是一个可以更轻松地添加命名 url 模式的函数。如果您真的不想命名您的网址，您可以编写自己的函数来自动为您生成名称。

【讨论】：

感谢您回复此 Alasdair。当我尝试做 {% url MyView.as_view %} 这不应该工作吗？在我看来，为什么需要将其分配为变量？我认为视图类继承了应该使它们可调用的 as_view() 函数？
MyView.as_view 不是可调用视图。这是一个返回可调用视图的方法。如果你不给变量赋值MyView.as_view()，它是一个匿名函数，所以不能反转。
pre-django1.3 当我们使用基于函数的视图时，为什么函数视图不被视为匿名函数（当我们以 url 模式传递它们时）？我的意思是我们基本上是在提供 url 函数方法，不是吗？它们恰好是我们定义为视图的东西。我没有看到调用基于类的 MyView.as_view() 与基于函数的 my_view() 之间的区别
我不确定你是否理解匿名函数是什么。我认为我无法比已有的更好地解释我的答案了。
重新阅读您的答案并重新思考，我想我现在明白了。感谢您抽出宝贵时间阐明您的解释@Alasdair。

【解决方案2】：

首先，这不是重复你自己。你在哪里命名 URL 两次？那会重复你自己。

其次，不需要为 url 模式命名 - 但有很多优点 - 这就是推荐的原因。它还为您提供了更改视图方法名称的灵活性，而无需更改模板。您可以决定一组 url 名称并将它们交给您的设计人员来处理模板，您可以按照自己喜欢的方式随意命名您的视图方法（或类）。

第三，您需要将 完整路径 传递给视图 method - 因此对于基于类的视图，它需要为 as_view，并确保您通过正确的参数数量和类型；并且不要混合位置参数和关键字参数。

或者，您可以通过命名您的 URL 模式来避免上述大部分情况。

【讨论】：

好答案。第二点特别重要it's one of Django's design philosophies (loose coupling)
@burhan 感谢您的快速回复和具体答复。我已经编辑了问题以包含一些代码。这就是您在 url 模板标签中使用“as_view”的意思吗？我确定我在这里遗漏了一些愚蠢的东西，但不确定是什么。
您需要为其提供可导入路径（这意味着也为其提供应用名称）。至于您在urls.py 上的示例，那里没有代码重复，除了您输入了几次“___view”。您在两个版本中都有确切的名称行数 - 四种 URL 模式。
@burhan =\ 不幸的是，提供可导入路径也不起作用。我修改了要点以显示我做了什么。这是你想要的吗？旁注： urls.py 示例不是显示我们如何重复行，而是显示行中的内容。我们在每一行中添加相同的语法并命名我们可能不必命名的东西。我想这取决于偏好。

【解决方案3】：

我不明白这是如何违反 DRY 原则的——它们都是不同的视图，做不同的事情，并且每个视图都被赋予一个唯一的标识符，以免在反转时发生冲突。如果有的话，使用命名 URL 将减少您必须在模板级别编写的代码并使您的 url 方案更具可读性

【讨论】：