【问题标题】:How is REQUEST object for a user in Django Views diffrentiated from one to another?Django Views 中用户的 REQUEST 对象如何区分?
【发布时间】:2017-07-24 15:51:18
【问题描述】:

我不确定我所做的是对还是错。但是这个功能让我发现了 Django Views 中发生的一个非常深奥的事件。

所以代码:

from django.contrib.messages import get_messages
from django.contrib import messages
#Other required modules.

@require_GET
def get_form(request):
    #code to get a form.
    storage = get_messages(request)
    for message in storage:
        message = message
    if message:
        context['message'] = message
    html = render(request , 'some_html.html' , context)
    return HttpResponse(html)

@require_POST
def submit_form(request):
    #Initialize a bounded form.
    if form.is_valid():
        form.save()
        messages.add_message(request, messages.INFO, success_message)
    else:
        messages.add_message(request, messages.INFO, error_message)    
        # ABOVE LINE IS WHERE THE ISSUE OCCURS
        return redirect('reverse_url_mapping_to_get_form') 
        # Above line is redirecting to "get_form" function(The function preceding this one).

ISSUE :现在我遇到的奇怪的事情发生在我在return redirect('reverse_url_mapping_to_get_form')(提到的代码的最后一行)中打错字。

显然我遇到了Django的错误页面,说有“NoReverseMatch”。 但是当我重新加载表单时(通过浏览器正常刷新,在“url”映射到get_form(request)),我发现我在messages.add_message(request, messages.INFO, error_message)行中添加的错误消息被带到了到 html(some_html.html)。甚至认为发生了错误,我从未成功重定向到该 url。

现在我知道messages.add_message() 有点捎带了请求,但是,它不应该在发生错误的情况下被销毁。重定向未成功执行的情况。

为什么重新加载时消息仍在请求对象中?

它不应该被销毁吗(因为它是一个完全独立的 GET 请求;我通过重新加载从浏览器启动它)?

提前致谢。

【问题讨论】:

    标签: django django-views django-messages django-request


    【解决方案1】:

    您完全误解了消息框架的工作原理。它不存储请求中的消息;它们存储在会话中。

    【讨论】:

    • 非常感谢您的回复。只是想问一下,如果有任何机会从get_messages(request) 向服务器发送请求的视图中没有提取消息,那么下次用户对服务器的请求命中时,它是否可能会被提取跨越get_messages(request),即使该消息不是针对服务器的特定请求?
    • 我不太明白你在问什么。添加后,消息会一直存在,直到显示为止。这在文档中有完整的解释。
    • 为这个令人困惑的问题道歉。我想知道消息是否持续存在。除此之外,我在文档中找到了我想要的东西。再次非常感谢。
    猜你喜欢
    • 2021-12-20
    • 2021-09-26
    • 2015-06-25
    • 1970-01-01
    • 1970-01-01
    • 2019-04-13
    • 2015-10-31
    • 1970-01-01
    • 2021-06-18
    相关资源
    最近更新 更多