我的 Django 视图如何知道要呈现哪个模板，或者是否返回 JSON？
我们的网站可以通过完整的浏览器、移动浏览器和自定义 iPhone 应用程序访问。由于无论客户端如何，逻辑基本上都是相同的，因此我们使用相同的视图来处理所有类型的请求。但在我们每个视图的底部，我们都有这样的东西：
if request.is_mobile():
return render_to_response('foo/bar/baz_mobile.html', context)
elif request.is_api():
return json.dumps(context)
else:
return render_to_response('foo/bar/baz.html', context)
显然有更好的方法来做到这一点:)
我想到了让我们的视图返回上下文字典，并将它们包装在一个装饰器中，该装饰器决定如何呈现响应。或者，也许我可以用基于类的视图做一些事情。
你会怎么做？
Our site can be accessed from a full browser, from mobile browsers, and from a custom iPhone app. Since the logic is mostly the same regardless of the client, we're using the same views to process all types of requests. But at the bottom of every one of our views, we have something like:
if request.is_mobile():
return render_to_response('foo/bar/baz_mobile.html', context)
elif request.is_api():
return json.dumps(context)
else:
return render_to_response('foo/bar/baz.html', context)
Clearly there's a better way to do it :)
I've thought of just having our views return the context dictionary, and wrapping them in a decorator that determines how to render the response. Alternatively, maybe there's something I can do with class-based views.
How would you do it?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
有一个返回字典的函数，然后有两个视图，其中一个将其编码为 JSON，另一个将其通过模板推送。
Have a function that returns a dict, and then have two views, one of which encodes it as JSON and the other that shoves it through a template.
伊格纳西奥·巴斯克斯·艾布拉姆斯是对的。
正如您所说，逻辑基本上是相同的 - 但逻辑不是视图。根据最初的 MVC 论文：“视图是其模型的（视觉）表示”。因此，您应该针对不同的目的拥有不同的视图，共享相同的逻辑。
Ignacio Vazquez-Abrams is right.
As you've said, logic is mostly the same - but logic is not view. According to the original MVC paper: "a view is a (visual) representation of its model". So you should have separate views for different purposes, sharing same logic.
如此处所述：
http://docs.djangoproject.com/en/ dev/ref/request-response/#attributes
因此，将视图中的请求参数包含到模板的上下文中：
在模板中提供：
哪些报告：
As described here :
http://docs.djangoproject.com/en/dev/ref/request-response/#attributes
So including the request argument from your view into the context of your template :
Provides thus in your template :
Which reports :