带有装饰器和会话的django类视图

我试图将一些django视图从基于函数的视图转换为基于类的视图，但遇到了一个小问题

我的OO有点弱，我认为问题在于我已经不知道事情的发展方向

我有一个自定义登录装饰，我需要的意见，所以我有

首先，我有这个例子中的视图类

然后我的视图类看起来像这样

class TopSecretPage(View):
    @custom_login
    def __call__(self, request, **kwargs):
        #bla bla view stuff...
        pass

def myuser_login_required(f):
    def wrap(request, *args, **kwargs):

        # this check the session if userid key exist,
        # if not it will redirect to login page

        if 'field' not in request.session.keys():
        return wrap

问题是由于某种原因，我的装饰程序无法访问request.session

我的装饰师看起来像这样

class TopSecretPage(View):
    @custom_login
    def __call__(self, request, **kwargs):
        #bla bla view stuff...
        pass

def myuser_login_required(f):
    def wrap(request, *args, **kwargs):

        # this check the session if userid key exist,
        # if not it will redirect to login page

        if 'field' not in request.session.keys():
        return wrap

我想我错过了一些简单的事情，所以谢谢大家的耐心

更新： 好的，这是我得到的错误

ViewDoesNotExist:在模块projectname.application.views中尝试了TopSecretPage。错误为：类型对象“TopSecretPage”没有属性“session”

我也简化了装潢师，使其看起来像这样

def myuser_login_required(request, *args, **kwargs):


    # this check the session if userid key exist,
    # if not it will redirect to login page

    if 'username' not in request.session.keys():
        return  HttpResponseRedirect(reverse("login-page"))

    return True

这个问题已经出现了。包括一个可能适合您的解决方案

更新：带有装饰器的示例方法：

class ContentView(View):

    # the thing in on_method() is the actual Django decorator
    #here are two examples
    @on_method(cache_page(60*5))
    @on_method(cache_control(max_age=60*5))
    def get(self, request, slug): # this is the decorated method
        pass #in here, you access request normally

---

您可以装饰url，而不是在视图上使用装饰器

例如，在URL.py中：

from my_decorators import myuser_login_required
from my_views import TopSecretPage

urlpatterns = patterns('', 
    (r'^whatever-the-url-is/$', myuser_login_required(TopSecretPage), {}),
)

---

您可能需要稍微处理一下，但这是正确的。

问题是，您的包装器期望“request”作为第一个参数，但类上的方法总是将“self”作为第一个参数。因此，在您的decorator中，它认为请求对象实际上是TopSecretPage本身

---

Vinay或artran的解决方案都应该有效，所以我不再重复。我只是想更清楚地描述这个问题可能会有所帮助。

对于任何应用于任何基于类的视图方法的装饰器来说，正确的方法是使用

django.utils.decorators.method\u decorator（）

。我不确定什么时候引入了方法_decorator（），但这里是Django 1.2中的一个示例/更新。像这样使用它：

from django.utils.decorators import method_decorator

class TopSecretPage(View):
    @method_decorator(custom_login)
    def __call__(self, request, **kwargs):
        #bla bla view stuff...
        pass

---

这实际上是一个复制品 它描述了解决这个问题的正确方法。django 1.9执行此操作的正确方法如下：

@method_decorator(myuser_login_required(), name='dispatch')
class TopSecretPage(View):
    ..

---

嗯，就像我说的，我的oop技能很弱，在发布这个问题之前，我已经读过了。在那个例子中，我看不到如何访问decorator函数中的request对象。感谢您的更新！但是我还是有问题，哈哈。我将更新我的问题以尝试展示它…对于Django 1.5，它是

@method\u decorator（cache\u control（max\u age=86400））def get（self，request，*args，**kwargs）：

我认为这个解决方案应该有效，但您需要实例化TopSecretPage:myuser\u login\u required（TopSecretPage（））您能引用吗？你是说基于类的视图是django 1.2所说的处理视图的方式吗？由于维护原因，我不再使用基于类的视图。请查看1.2发行说明的这一部分：@ThomasSchultz什么是维护原因？你是否建议人们避免基于类的观点，到目前为止我与他们没有任何问题。我怀疑这更像是一个纪律问题。我们发现，基于类的视图往往增长迅速，增加了很多复杂性。此外，还有很多诱惑，开始更多地复制代码。然后你开始有一些类似“基本”视图类之类的东西。我们发现，我们可以使用更易于维护、更不复杂、更易于调试的函数视图。不过这只是我们的经验。类视图确实有效，我们使用它们将近2年了。