使用ETag / Last-Modified装饰器与Django的基于类的通用视图 [英] Using ETag / Last-Modified decorators with Django's class-based generic views

问题描述

我最近将我的一个Django项目中的所有视图迁移到新的基于类的项目。对于经典功能的Django视图，有一个方便的装饰器 django.views.decorators.http.condition ，可以用来绕过整个视图处理，如果有一个缓存的副本匹配你指定的条件我在文档和源代码中搜索到无处不在，但是找不到新的基于类视图的任何实现。

所以我的问题是：你如何建议我为基于类的视图实现条件视图处理？

解决方案

看起来不是很好回答这个问题。对于仅设置函数属性的装饰器（例如 csrf_exempt ），只需将它们应用于视图类的调度方法即可，但这显然不适用于条件 decorator，因为他们期望第一个函数参数是请求对象，而不是 self 。

您可以通过以下两种方式来实现：

1. 将修饰器应用于生成的视图函数。通用视图功能真的归结为从类构建视图函数的方法，所以将decorator应用到晚期可能是一个选项。如下所示：

     f = ViewClass.as_view（）
   f =条件（...）（f）
     

   这样做的缺点是您无法从传递给条件装饰器。如果您在urlconf中调用 as_view 方法也不是很方便。




2. 代表到一个简单的功能，你可以将装饰器应用到视图的 dispatch 方法内。如下所示：

     def dispatch（self，request，* args，** kwargs）：
    @condition ...）
    def _dispatch（request，* args，** kwargs）：
    return super（ViewClass，self）.dispatch（request，* args，** kwargs）
    return _dispatch （请求，* args，** kwargs）
     

   这个有一个好处，你可以访问在应用装饰器时查看类实例，因此可以为缓存验证功能使用实例方法。缺点是装饰器将在每次调用视图时运行，但对于这个特定的装饰器来说，这不是一个问题。

这两个解决方案都有问题，所以也许值得提交一个错误报告，或者在django-users邮件列表中询问这两个概念应该如何组合起来。

I've recently migrated all views in one of my Django projects to the new class-based ones. For classic function-based Django views there's a handy decorator django.views.decorators.http.condition that can be used to bypass the whole view processing if there's a cached copy matching the conditions that you've specified. I've searched everywhere in the docs and in the source code but can't find any implementation of this for the new class-based views.

So my question is: How would you suggest that I implement conditional view processing for class-based views?

解决方案

It looks like there isn't a nice answer to this problem yet. For decorators that just set function attributes (e.g. csrf_exempt), it is enough to apply them to the view class's dispatch method, but that obviously doesn't work for the condition decorator, since they expect the first function argument to be a request object rather than self.

Two ways you could achieve this include:

1. Apply the decorator to the generated view function. The generic view functionality really boils down to a way of building view functions from classes, so applying the decorator late might be an option. Something like this:

   f = ViewClass.as_view()
   f = condition(...)(f)
   

   This has the disadvantage that you don't have access to the view class from the functions you pass to the condition decorator. It is also not very convenient if you're calling the as_view method in the urlconf.

2. Delegate to a simple function you can apply decorators to inside your view's dispatch method. Something like this:

   def dispatch(self, request, *args, **kwargs):
       @condition(...)
       def _dispatch(request, *args, **kwargs):
           return super(ViewClass, self).dispatch(request, *args, **kwargs)
       return _dispatch(request, *args, **kwargs)
   

   This one has the benefit that you have access to the view class instance when applying the decorator, so you could use instance methods for your cache validation functions. A downside is that the decorator will be run every time the view is invoked, but that doesn't look like a problem for this particular decorator.

Both solutions have their problems though, so perhaps it would be worth filing a bug report or asking on the django-users mailing list about how these two concepts should best be combined.

这篇关于使用ETag / Last-Modified装饰器与Django的基于类的通用视图的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！