In this case it may also be useful to have the app for error handling, in the event that the middleware doesn’t correctly handle a request and tries to pass it on to the wrapped app. If your middleware doesn’t have this flexibility then you will need to provide an app for it to wrap, as you have in your example. It stores the app in the initializer if it is given, and then when a request arrives that doesn’t match any route it uses the presence of to decide whether to behave as middleware and pass the request on, or to behave as the final app and treat it as a not found error. This is what Sinatra does to allow it to be used as middleware.
Devise simple rack app full#
If your middleware is written in such a way that it can handle having no arguments passed to its initializer and it will behave like a full app, then you may be able to use it directly as the app in : run SomeMiddleware.new The DSL expects there will always be either a run or map statement, you will get an error if you omit both. This is the (not well documented) “interface” to Rack middleware: the first argument to its initializer is the app it is wrapping, the rest are any other arguments passed to use. A new instance of the middleware class is created, with the existing app passed as the first argument of the constructor, and the resulting object becomes the new app. It’s a little more complex than this, but this is the general idea. The use method stores the middleware classes you want to include in your app, and then when constructing the final app does something like this for each one (in reverse order of how they appear in the file): = other_args) The run method just sets the “base” app: def = app When using a rackup file, Rack uses the DSL described in Rack::Builder. A Rack app (including middleware) is basically just an object that responds to call, accepting a hash describing the request and returning an array describing the response.
0 kommentar(er)
