Decoupling from Gorilla Mux about goth HOT 6 OPEN

+1

from goth.

@rickb777 there is a minor difference in the first code what on first looks like the same:
the second req.URL.Query().Get(":provider") is with a semicolon before the provider
So think it has to do with resolving the provider value in side the different http engines

@markbates binding against mux is indeed a problem , but I know when we would change this it would break applications using this default behavior . Any thoughts on how to decouple this?

I also changed the GetProviderName function to a custom function to do my own implementation when using Macaron , but this does indeed not remove the gorilla/mux dependency on the project.

from goth.

This coupling has been there for a few years, and to remove it would break existing apps. If someone can figure out a way to do this would breaking backward compatibility I'm all ears.

from goth.

@markbates what about a v2 sub-package in-line with Go module design?

Some common functionality could be moved into an internal package and exported by both while the v2 package could be built without being coupled to gorilla/mux and the old package could remain as is.

from goth.

As for the backwards compatible approach Both gorilla/mux and httperouter can use context.Content to find route parameters. I've done a simple context.Values check in my "mid" middleware.

from goth.

Has there been any follow-up on this? Would be nice to remove the dependency on gorilla packages (both Store and url param functionality), and make it a bit more pluggable. Could also have sub-packages to still allow the use of gorilla packages in a seamless way. I don't think there is an easy way to be backwards compatible, but might be worth a v2 version, with an interface/context approach.

Would @markbates or other maintainers be open to supporting something like this? I could potentially help with PR's and whatnot.

EDIT: /cc @techknowlogick

from goth.