Access to requests before dispatching URI.

[myguidingstar-zz]

It's nice to have Sinatra-like routing engine in FoxxController. However, there should be an option to access to requests before dispatching URI.

FYI, I want to implement a (Clojurescript) bidi router other than a Sinatra-style one with Foxx.

https://github.com/juxt/bidi
arango-cljs/forest#9

[myguidingstar-zz]

This nodejs example may make it clearer

// Load the http module to create an http server.
var http = require('http');

// Configure our HTTP server to respond with Hello World to all requests.
var server = http.createServer(function (request, response) {
  response.writeHead(200, {"Content-Type": "text/plain"});
  response.end("Hello World\n");
});

// Listen on port 8000, IP defaults to 127.0.0.1
server.listen(8000);

[pluma]

I'm not entirely sure I understand your question. What is your node example meant to illustrate?

[myguidingstar-zz]

Sorry for that confusing illustration. I want to have a request handler that listen to any type of HTTP method (so that I can implement my own request dispatcher that doesn't follow the Sinatra style)

[myguidingstar-zz]

So instead of

app.get('/goose/barn', function (req, res) {
// Take this request and deal with it!
});

I want something as low-level as

app.any(function (req, res) {
// Take this request and deal with it!
});

[myguidingstar-zz]

Of course this type of handler still lies between before and after hooks

[pluma]

I can see how you'd find such a method useful. I think in express the equivalent is called all and the idea is that it allows you to avoid repeating yourself for otherwise identical methods that just behave slightly differently depending on the HTTP verb.

I'm not sure how easy this would be to do, though. The internals generally assume a 1-to-1 mapping between HTTP verbs and route handlers. A naive solution would be to just add a method that simply invokes controller.get, controller.post, etc with the same arguments, but that has all kinds of potential for errors.

A more robust solution would be to implement an actual fallback route handler, but I'm not sure how difficult this would be to implement. The most obvious problem would be the generated documentation (which currently expects each handler to support exactly one HTTP verb).

@moonglum, @fceller, any thoughts on this?

[fceller]

See also discussion https://groups.google.com/forum/?hl=de#!topic/arangodb/eWi8L9bTkEk

[pluma]

@fceller, I'm not sure the two questions are about the same thing. As I understand it, the Google Groups question is about having controller.before intercept route handlers that are currently implemented in C++. The feature request is about having route handlers analogous to controller.post (etc) that are used if no other route handler for the request method (HTTP verb) matches the route.

[myguidingstar-zz]

@pluma The two are not the same. Btw, .any method not only ignore request types (aka HTTP verbs) but also the income request's path attribute

[pluma]

@myguidingstar I think with the change in #1023 this use case can now be solved with code like this:

ctrl.before('/*', function (req, res) {
  res.json({hello: 'world', from: req.path});
  return false;
});

usage:

$ curl http://localhost:8529/_db/_system/my_foxx_app/some/random/path
{
  "hello": "world",
  "from": "/some/random/path"
}

Is this sufficient?

EDIT: This probably doesn't work for paths that don't have any route handlers defined, though. :/

[jsteemann]

Is the implementation in #1023 actually doing what it required?
It would be helpful to get feedback on this so we know what to do and probably close this issue.
Thanks!

[myguidingstar-zz]

Things I've learn about before and around through #1040 would help. Thanks