我有两个问题。由于它们彼此相关,我在一个帖子中询问它们。
1)在Django应用程序中广泛使用会话是一种好习惯吗?我做了一个测验应用程序,每个问题都是动态制作并存储在会话中。当用户回答第一个问题时,生成第二个问题并将其保存在与第一个问题相同的会话变量中,依此类推。我还使用会话来跟踪正确答案的数量,回答的问题,下一个问题的ID以及一些其他变量。在我见过的所有django应用程序中,虽然很小,但却充满了request.session。这是正常的吗?或者你建议一个更好的方法?
2)由于这个应用程序都是基于会话的,如果我在同一浏览器中打开一个新选项卡,并输入测验的网址,它将从剩下的其他选项卡的位置进行选择。如何限制标签彼此看到?
由于
答案 0 :(得分:1)
1)在Django应用程序中广泛使用会话是一种好习惯吗?
我认为你应该重新制定你的问题,以考虑会话的本质是否适合你想要实现的目标。了解如何在Django中使用会话。会话ID存储在cookie中,因此基本上会话生存期和行为直接受Cookie的性质影响。
让自己置身于不了解何时以及如何(或甚至)操纵cookie的用户的心中。如果您最终得到“我不在乎系统是否由于某些抽象的技术原因而不记得我(例如关闭浏览器,通过清除浏览器的历史记录手动重置并意外删除cookie等)。”然后会议我是一个很好的方式。
恕我直言,Django可以很容易地将问题存储在我通常用于创建帐户和数据库使用的数据库中,而不会问自己这个问题。
2)由于这个应用程序都是基于会话的,...我如何限制标签彼此看到?
然后你不应该使用Django会话,因为它们基于cookie,这是这种行为背后的真正罪魁祸首。由于这是一个测验类型的东西,我假设你在每个页面上至少有一个表格。生成某种自定义会话ID并将其存储在隐藏的表单字段中。您也可以将它存储在查询字符串中,但这不是“Django-ish”。
答案 1 :(得分:0)
如果您不需要超出会话提供的数据持久性,那么仅使用会话是完全正常的。这可能是显而易见的,但如果你想保存与登录用户相关的结果,问题和答案,你至少需要深入研究Django的模型。
您始终可以使用URL参数(存储在request.GET中)来区分浏览器选项卡;如果在没有URL参数的情况下加载新页面,则生成随机值并重定向到URL,并将随机值作为URL参数附加。使用URL参数值作为会话密钥结构的一部分,以区分浏览器选项卡数据。