GitHub/gitea - gitea - Gitea: Git with a cup of tea

Author	SHA1	Message	Date
wxiaoguang	4e2f1ee58d	Refactor web package and context package (#25298 ) 1. The "web" package shouldn't depends on "modules/context" package, instead, let each "web context" register themselves to the "web" package. 2. The old Init/Free doesn't make sense, so simplify it * The ctx in "Init(ctx)" is never used, and shouldn't be used that way * The "Free" is never called and shouldn't be called because the SSPI instance is shared --------- Co-authored-by: Giteabot <teabot@gitea.io>	3 years ago
wxiaoguang	abcf5a7b5e	Fix install page context, make the install page tests really test (#24858 ) Fix #24856 Rename "context.contextKey" to "context.WebContextKey", this context is for web context only. But the Context itself is not renamed, otherwise it would cause a lot of changes (if we really want to rename it, there could be a separate PR). The old test code doesn't really test, the "install page" gets broken not only one time, so use new test code to make sure the "install page" could work.	3 years ago
wxiaoguang	6b33152b7d	Decouple the different contexts from each other (#24786 ) Replace #16455 Close #21803 Mixing different Gitea contexts together causes some problems: 1. Unable to respond proper content when error occurs, eg: Web should respond HTML while API should respond JSON 2. Unclear dependency, eg: it's unclear when Context is used in APIContext, which fields should be initialized, which methods are necessary. To make things clear, this PR introduces a Base context, it only provides basic Req/Resp/Data features. This PR mainly moves code. There are still many legacy problems and TODOs in code, leave unrelated changes to future PRs.	3 years ago
wxiaoguang	92fd3fc4fd	Refactor "route" related code, fix Safari cookie bug (#24330 ) Fix #24176 Clean some misuses of route package, clean some legacy FIXMEs --------- Co-authored-by: Giteabot <teabot@gitea.io>	3 years ago
wxiaoguang	b9a97ccd0e	Refactor web route (#24080 ) The old code is unnecessarily complex, and has many misuses. Old code "wraps" a lot, wrap wrap wrap, it's difficult to understand which kind of handler is used. The new code uses a general approach, we do not need to write all kinds of handlers into the "wrapper", do not need to wrap them again and again. New code, there are only 2 concepts: 1. HandlerProvider: `func (h any) (handlerProvider func (next) http.Handler)`, it can be used as middleware 2. Use HandlerProvider to get the final HandlerFunc, and use it for `r.Get()` And we can decouple the route package from context package (see the TODO). # FAQ ## Is `reflect` safe? Yes, all handlers are checked during startup, see the `preCheckHandler` comment. If any handler is wrong, developers could know it in the first time. ## Does `reflect` affect performance? No. https://github.com/go-gitea/gitea/pull/24080#discussion_r1164825901 1. This reflect code only runs for each web handler call, handler is far more slower: 10ms-50ms 2. The reflect is pretty fast (comparing to other code): 0.000265ms 3. XORM has more reflect operations already	3 years ago