Return route variable values for a request

[xenosdio]

Would it make sense in Patron's http router component to include a function for returning the route variable values for a request?

Currently, developers should rely on the internal http framework used by Patron, i.e. httprouter, in order to fetch them. It would be a nice addition if this could be done directly through Patron.

This way also, if for example the internal http framework were to be replaced, developers would only just update Patron.

WDYT?

[mantzas]

We did try to abstract things away in v1 and the implementation was very leaky.
Everybody wanted to have access to some internal thing and we extended it further until we actually exposed almost everything from http.Request.
v2 was introduced to allow developers to do whatever they feel.
What might be missing is some helper function to make things easier, right?

[xenosdio]

That's what I had in mind, yes. To use a Patron helper function, instead of calling the respective helper function of the internal http framework.

[mantzas]

There is one problem with this approach...
Different routers handle things differently so we might provide helper function per supported router. If this is the case why not use the specific router helper function itself? Otherwise we need to let the helper function know for which router we need to handle.
httprouter is very simple and has actually nothing like that so we need to provide the implementation for that.

[xenosdio]

httprouter is very simple and has actually nothing like that so we need to provide the implementation for that.

If I am not mistaken, httprouter's implementation for the aforementioned is the following:
https://github.com/julienschmidt/httprouter/blob/master/router.go#L120

Apart from that, does Patron support currently (or in the future) more than one http frameworks internally? Because if not, this function could be the one and only responsible for returning the variables, by wrapping the respective function from the internal framework.

[mantzas]

Actually v2 component of Patron allow you to plug in any router that supports the http.Handler interface:

// New creates an HTTP component configurable by functional options.
func New(handler http.Handler, oo ...OptionFunc) (*Component, error) {

In Patron we provide now the http router implementation. In the future we might want to support also gorilla/mux because it is a much more complete router.
There are things that httprouter cannot do nicely. The work to provide an implementation for gorilla/mux is not insignificant if we want to be feature compatible with the existing router we implemented.
That's why providing generic helper methods are tricky because the have to know which router you are using and such an abstraction will be hard to not leak implementation details from different routers.
Makes sense?