-
Notifications
You must be signed in to change notification settings - Fork 8.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Method to get main handler is desired #928
Comments
collinmsn
pushed a commit
to collinmsn/gin
that referenced
this issue
Jun 2, 2017
Fix gin-gonic#928 Method to get main handler is desired
collinmsn
pushed a commit
to collinmsn/gin
that referenced
this issue
Jun 2, 2017
Fix gin-gonic#928 Method to get main handler is desired
collinmsn
pushed a commit
to collinmsn/gin
that referenced
this issue
Jun 2, 2017
Fix gin-gonic#928 Method to get main handler is desired
collinmsn
pushed a commit
to collinmsn/gin
that referenced
this issue
Jun 2, 2017
Fix gin-gonic#928 Method to get main handler is desired
collinmsn
pushed a commit
to collinmsn/gin
that referenced
this issue
Jun 2, 2017
Fix gin-gonic#928 Method to get main handler is desired
appleboy
pushed a commit
that referenced
this issue
Jun 2, 2017
Fix #928 Method to get main handler is desired
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
It's convenient to get request handler name by gin.Context.HandlerName, but it not always work well. In case that handler is installed with decorator wrapped, HanderName will return func1, which is meaningless.
r.GET("/foo", Decorator(Foo))
Since there's no way to get function name of wrapped func, it can resort to user passing this value explicitly. Something like r.GETEX("/foo", Decorator(Foo), "Foo")
Then I can save function point to name map on handler register and get handler name in middleware,
as long as I can get FuncHandler with ctx.
So it's desired to add a method to return main handler.
The text was updated successfully, but these errors were encountered: