Понимание обработчиков на Ring and Appengine-magic (Clojure)

Question

Я начал работать над некоторыми веб-приложениями clojure и решил использовать комбинацию Ring + Compojure. Недавно я решил попробовать Google Appengine с помощью AppEngine-magic (https://github.com/gcv/appengine-magic). Однако как appengine-magic (через функцию запуска), так и функция run-jetty для звонка только принимают 1 обработчик в качестве параметра, я реализую несколько обработчиков и хотел бы знать, как их развернуть.

Спасибо заранее, Ze

Answer 1

Всегда есть только один обработчик верхнего уровня - в конце концов, даже если на каком-то концептуальном уровне есть несколько обработчиков, приложение должно решить, какой из них применить к данному запросу так или иначе, поэтому процедура, которая делает выбор получателем верхнего уровня. Итак, короткий ответ заключается в том, что вам нужно предоставить функцию, которая будет рассматривать запрос и передать его соответствующему обработчику среди нескольких обработчиков внутри вашего приложения; эта функция является обработчиком, который должен быть присвоен run-jetty (или эквивалент).

Обычно с Ring + Compojure у вас есть базовые («внутренние») обработчики, предназначенные для обработки определенных URI и некоторых специальных обработчиков (скажем, для 404), реализованных в качестве промежуточного программного обеспечения. Первые, как правило, определяются в формах defroutes, а последние - функции более высокого порядка.

Обработчики промежуточного программного обеспечения сами решают - посмотрев запрос - хотите ли они немедленно вернуть ответ или делегировать обработчикам, они обернуты. «Внутренние» обработчики на основе маршрута вызываются для соответствующих URI и имеют возможность возвращать nil, чтобы указать, что запрос не имеет для них смысла (после чего проверяются остальные обработчики на основе маршрутов, если все nil , окончательный ответ обычно генерируется некоторым фрагментом промежуточного программного обеспечения, возможно, возвращением 404).

Я написал длинный ответ относительно Compojure here; возможно, это может помочь в сборе определений обработчиков на основе маршрутов Compojure.

Answer 2

Я не знаю, если это лучший подход, я в конечном итоге реализации функции ring.middleware, что оборачивает другие обработчики вокруг основного одного:

(defn wrap-ohandler [f handler] 
    (fn [req] 
    (let [ res (f req) ] 
     (if (= res nil) (handler req) res)))) 

(def handler-wrapped 
    (-> #'main-handler 
    (wrap-ohandler #'anotherhandler) 
    (wrap-stacktrace) 
    (wrap-params))) 

Это работает, но это хороший подход?