了解 Ring 和 Appengine-magic (Clojure) 上的处理程序
我开始开发一些 clojure Web 应用程序，并决定使用 Ring + Compojure 的组合。 最近我决定尝试使用 Google Appengine 和 AppEngine-magic (https://github.com/gcv/appengine-magic)。然而，appengine-magic（通过它的启动函数）和ring的run-jetty函数都只接受1个处理程序作为参数，我正在实现几个处理程序，并且想知道如何部署它们。
提前致谢， 泽
I started working on some clojure web apps and decided to use a combination of Ring + Compojure.
Recently I decided to try Google Appengine with AppEngine-magic (https://github.com/gcv/appengine-magic). However both appengine-magic (through it's start function) and ring's run-jetty function only take 1 handler as a parameter, I'm implementing several handlers and would like to know how to deploy them all.
Thanks in advance,
Ze
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
总是只有一个顶级处理程序 - 毕竟，即使在某个概念级别有多个处理程序，应用程序也需要以某种方式决定将哪一个处理程序应用于给定的请求，因此做出选择的例程变为顶级处理程序。因此，简短的答案是，您需要提供一个函数来查看请求并将其传递给应用程序内多个处理程序中的适当处理程序；该函数是要提供给 run-jetty （或等效函数）的处理程序。
通常，使用 Ring + Compojure，您将拥有一些用于处理特定 URI 的基本（“内部”）处理程序和一些作为中间件实现的特殊用途处理程序（例如，用于 404）。前者往往以 defroutes 形式定义，而后者是高阶函数。
中间件处理程序在查看请求后自行决定是要立即返回响应还是委托给它们所包围的处理程序。基于路由的“内部”处理程序被调用以获取适当的 URI，并且可以选择返回 nil 来指示该请求对它们来说没有意义（此时剩余的基于路由的处理程序尝试；如果全部
nil，则最终响应通常由某个中间件生成，可能返回 404）。我在此处写了一篇关于Compojure的冗长答案;也许它可能对掌握 Compojure 基于路由的处理程序定义有所帮助。
There's always going to be only one top-level handler -- after all, even if at some conceptual level there are multiple handlers, the app needs to decide which one to apply to a given request somehow, so the routine which makes the choice becomes the top-level handler. So, the short answer is that you need to provide a function which will look at a request and hand it off to the appropriate handler among the several handlers inside your app; that function is the handler to be given to
run-jetty(or the equivalent).Normally with Ring + Compojure you'd have some basic ("inner") handlers meant for handling particular URIs and some special-purpose handlers (say, for 404s) implemented as middleware. The former tend to be defined in
defroutesforms, while the latter are higher order functions.The middleware handlers decide for themselves -- after looking at the request -- whether they want to return a response immediately or to delegate to handlers they are wrapped around. The route-based "inner" handlers are called upon for appropriate URIs and have the option of returning
nilto indicate that the request doesn't make sense to them (at which point the remaining route-based handlers are tried; if allnilout, the final response is normally generated by some piece of middleware, possibly returning a 404).I've written a lengthy answer concerning Compojure here; perhaps it might be of some help in getting the hang of Compojure's route-based handler definitions.
我不知道这是否是最好的方法，我最终实现了一个 Ring.middleware 函数，它将其他处理程序包装在主要处理程序周围：
这可行，但这是一种好方法吗？
I don't know if this is the best approach, I ended up implementing a ring.middleware function that wraps the other handlers around the main one:
This works, but is this a good approach ?