新手:过滤器是否是根据请求参数修改响应数据的正确位置?

发布于 2024-12-04 17:03:04 字数 672 浏览 1 评论 0原文

我的问题很简单:在一个平均复杂的网络请求中,通常我们在请求参数方面有相当多的信息。在许多情况下,如果请求来自点击第三方网站上的链接或来自电子邮件通讯。

另一个例子:在 quora 上,如果输入以下 url: http://www.quora.com/As-a-mobile-apps-developer-on-what-platform-should-I-choose-to-develop-and-why 您将被引导至正常网页,但是,如果您输入相同的网址,但末尾带有 (snids=24082824) 参数,您将获得页面内容以及一些额外的覆盖内容(在这种情况下,有关谁最后编辑了问题的信息)

我认为检查控制器操作中每个请求参数的存在性和值是愚蠢的。这会将动作置于 if-else if-else 汤中。

过滤器似乎是打破和解耦请求的所有不同元素的更好选择,对吧?使用过滤器,一次可以在短短几秒钟内完全改变工作流程,而不会破坏和扰乱控制器操作。控制器操作用于根据请求的 url 模式获取视图,但过滤器有责任修改请求/响应、拦截、记录甚至覆盖控制器操作(如果其中存在更多参数糖)的要求,对吗?

My question is very simple: In an averagely complex web request, usually we have quite a lot of information in terms of request parameters. In many cases some of those parameters are such that the controller action should not ever even be interested in, such as for example referrer_id, (for analytics purposes) if the request came from clicking a link on a third-party website, or from an email newsletter.

Another example: On quora, if you enter the following url:
http://www.quora.com/As-a-mobile-apps-developer-on-what-platform-should-I-choose-to-develop-and-why
you will be led to the normal web page, however, if you enter the same url, but with the (snids=24082824) parameter at the end, you get the page content, plus some additional overlaying content (In this case, information about who edited the question last)

I think to it would be stupid to check for the existence and values of every single request parameter in the controller action. That would urn the action in an if-else if-else soup.

Filters seem a much better alternative to break and decouple all the varying elements of a request, right? Using filters, once could completely change the workflow in mere seconds, without breaking and messing with controller actions. Controller actions are there to grab a view based on the url pattern of the request, but it is a duty of the filters to modify the request/response, intercept, log, or even override controller actions, if there is some more parameter sugar in the request, right?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

离线来电— 2024-12-11 17:03:04

只是一个小注释,我不会使用过滤器来修改请求和响应。鉴于这些对象可用于过滤器,这是可能的。使用过滤器做一些小事情来保持操作干净,或者强制执行特定于应用程序的访问控制听起来不错。但如果它是关于修改请求和响应,那么我更喜欢自定义 Rack 中间件。毕竟每个 Rails 应用程序都是机架应用程序。

Just a small note, I wouldnt use filters to modify the request and response. It is possible given that those objects are available to the filters. Using filters to do small time things that would keep the actions clean, or enforce access controls specific to an application sounds nice. But if its about modifying the request and response then I would prefer a custom Rack middleware. After all every rails app is a rack app.

鱼忆七猫命九 2024-12-11 17:03:04

是的,过滤器是正确的选择。

Yes filters is the right way to go.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文