django 1.3 url模板标记和基于类的视图

我刚刚开始将一个应用程序从1.1迁移到1.3

我开始接触到大量基于类的视图，我被这些视图吓坏了，但不是很好。 我有些不满，但具体问题是：

这是唯一可以将url模板标记与基于类的通用视图一起使用的方法吗？ i、 e.必须命名每个url条目

在我看来，这似乎很可笑，因为Django的基本哲学之一是枯燥的，而我们却在这里。。。。正在进行

提前谢谢

编辑： 所以我有

并获取错误 模板语法错误 呈现时捕获到NoReverseMatch:找不到具有参数和关键字参数“{}”的“views.HomeView.as_view”的反转

我用错了吗

切线： 我想进一步解释一下，如果我们必须命名urls.py文件中的每个条目，为什么我认为我们正在尝试

my URL.py通常看起来像

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

---

也许这应该扩展到一个单独的问题上。

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

第二，url模式的命名不是必需的，但有很多优点，这就是为什么推荐它的原因。它还为您提供了更改视图方法名称的灵活性，而无需更改模板。您可以决定一组url名称，并将它们交给您的设计师来处理模板，您可以自由地按照自己喜欢的方式命名视图方法或类

第三，需要将完整路径传递给view方法，因此对于基于类的视图，它需要是as_view，并确保传递正确数量和类型的参数；不要混合使用位置参数和关键字参数

---

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

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

第二，url模式的命名不是必需的，但有很多优点，这就是为什么推荐它的原因。它还为您提供了更改视图方法名称的灵活性，而无需更改模板。您可以决定一组url名称，并将它们交给您的设计师来处理模板，您可以自由地按照自己喜欢的方式命名视图方法或类

第三，需要将完整路径传递给view方法，因此对于基于类的视图，它需要是as_view，并确保传递正确数量和类型的参数；不要混合使用位置参数和关键字参数

---

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

我不认为这违反了DRY原则-它们都是独立的视图，做不同的事情，并且每个视图都有一个唯一的标识符，以便在反转时不会发生冲突。如果有什么不同的话，使用命名url将减少您必须在模板级别编写的代码，并使您的url方案更具可读性

我看不出这是如何违反DRY原则的-它们都是独立的视图，执行不同的操作，并且每个视图都被赋予一个唯一的标识符，以便在反转时不会发生冲突。如果说有什么区别的话，那么使用命名url将减少您必须在模板级别编写的代码，并使您的url方案更具可读性

这里有一个相当令人激动的解释，解释了为什么您不能在不命名的情况下反转基于类的视图。我不太熟悉Django的内部结构，所以我很高兴被纠正

使用基于函数的视图

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

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

您可以反转my_app.views.my_视图，因为它是可调用视图函数的路径

使用基于类的视图

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

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

无法反转my_app.views.MyView，因为它不是可调用的视图对象。可调用的视图是MyView.as\u视图。如果将MyView.as_视图指定给视图中的变量，如下所示：

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

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

然后，您就可以不命名它而反转我的视图。这个选项就像给你的url命名一样重复，所以我认为你不会喜欢它的

但是，当您将MyView.as_视图直接放在url模式中时，它是一个匿名函数。它还没有分配给任何变量，因此没有可以用于反转它的路径。同样，您也无法逆转以下情况：

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

---

请注意，这基本上只是一个使添加命名url模式更容易的函数。如果您真的不想命名URL，您可以编写自己的函数，自动为您生成名称。

这里有一个非常简单的解释，解释了为什么不能反转基于类的视图 没有命名。我不太熟悉Django的内部结构，所以我很高兴被纠正

使用基于函数的视图

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

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

您可以反转my_app.views.my_视图，因为它是可调用视图函数的路径

使用基于类的视图

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

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

无法反转my_app.views.MyView，因为它不是可调用的视图对象。可调用的视图是MyView.as\u视图。如果将MyView.as_视图指定给视图中的变量，如下所示：

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

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

然后，您就可以不命名它而反转我的视图。这个选项就像给你的url命名一样重复，所以我认为你不会喜欢它的

但是，当您将MyView.as_视图直接放在url模式中时，它是一个匿名函数。它还没有分配给任何变量，因此没有可以用于反转它的路径。同样，您也无法逆转以下情况：

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

---

请注意，这基本上只是一个使添加命名url模式更容易的函数。如果您真的不想命名URL，您可以编写自己的函数，自动为您生成名称。

回答得好。第二点特别重要，因为@burhan感谢您的快速回复和具体回答。我对问题进行了编辑，添加了一些代码。这就是您在url模板标记中使用as_视图的意思吗？我肯定我遗漏了一些愚蠢的东西，但不确定是什么。你需要给它一个可导入的路径，也就是说给它一个应用程序名。至于您在上的示例，这里没有代码重复，除了您要输入几次“\uuuuuuuuuuu view”。在这两个版本中，您都有确切的名称行数-四个URL模式。@burhan=\不幸的是，提供可导入路径也不起作用。我修改了要点以显示我所做的。这是你想要的吗？旁注：url.py示例并不是要显示我们如何重复行，而是要显示行中的内容。我们在每一行中添加相同的语法，并命名可能不需要命名的东西。我想这可以归结为偏好。回答得好。第二点特别重要，因为@burhan感谢您的快速回复和具体回答。我对问题进行了编辑，添加了一些代码。这就是您在url模板标记中使用as_视图的意思吗？我肯定我遗漏了一些愚蠢的东西，但不确定是什么。你需要给它一个可导入的路径，也就是说给它一个应用程序名。至于您在上的示例，这里没有代码重复，除了您要输入几次“\uuuuuuuuuuu view”。在这两个版本中，您都有确切的名称行数-四个URL模式。@burhan=\不幸的是，提供可导入路径也不起作用。我修改了要点以显示我所做的。这是你想要的吗？旁注：url.py示例并不是要显示我们如何重复行，而是要显示行中的内容。我们在每一行中添加相同的语法，并命名可能不需要命名的东西。我想这取决于偏好。谢谢你回复这个阿拉斯代尔。当我尝试执行{%url MyView.as_view%}时，这不应该起作用吗？在我看来，为什么需要将其指定为变量？我认为视图类继承了as_view函数，这应该使它们可以调用？MyView.as_view不是一个可调用的视图。它是一个返回可调用视图的方法。如果不将MyView.as_view分配给变量，则它是一个匿名函数，因此无法反转。在django1.3之前，当我们使用基于函数的视图时，为什么在url模式中传递函数视图时不将其视为匿名函数？我的意思是，我们基本上是在提供url函数方法，不是吗？它们恰好就是我们定义的视图。我看不出调用基于类的MyView.as_view和基于函数的my_view有什么区别。我不确定您是否理解匿名函数是什么。我不认为我能解释我的答案比我已经解释的更好。重新阅读你的答案并重新思考，我想我现在明白了。感谢您花时间解释@Alasdair。感谢您回复此Alasdair。当我尝试执行{%url MyView.as_view%}时，这不应该起作用吗？在我看来，为什么需要将其指定为变量？我认为视图类继承了as_view函数，这应该使它们可以调用？MyView.as_view不是一个可调用的视图。它是一个返回可调用视图的方法。如果不将MyView.as_view分配给变量，则它是一个匿名函数，因此无法反转。在django1.3之前，当我们使用基于函数的视图时，为什么在url模式中传递函数视图时不将其视为匿名函数？我的意思是，我们基本上是在提供url函数方法，不是吗？它们恰好就是我们定义的视图。我看不出调用基于类的MyView.as_view和基于函数的my_view有什么区别。我不确定您是否理解匿名函数是什么。我不知道

---

我想我能解释我的答案比我已经解释得更好。重新阅读你的答案，再仔细考虑一下，我想我现在明白了。感谢您花时间在阿拉斯代尔清楚地阐述您的解释。