Skip to content

interp: add ExecHandlers to support exec middlewares - #964

Merged
mvdan merged 1 commit into
masterfrom
handler-middleware
Jan 22, 2023
Merged

mvdan merged 1 commit into
masterfrom
handler-middleware

Conversation

@mvdan

@mvdan mvdan commented Jan 15, 2023

Copy link
Copy Markdown
Owner

(see commit message)

For #93.

Comment thread interp/api.go Resolved
Comment thread interp/api.go Resolved
Comment thread interp/api.go Resolved
Comment thread interp/api.go Resolved
Comment thread interp/api.go Resolved
The tests and examples were already using a form of middlewares.
For example, ExampleExecHandler would handle some specific cases,
and fall back to DefaultExecHandler.

However, this fall back was hard-coded to DefaultExecHandler.
The function wasn't a reusable middleware because of that.

Instead, borrow the design of middlewares from go-chi:

	func (mx *Mux) Use(middlewares ...func(http.Handler) http.Handler)

In such an API, each middleware is a function which takes "next",
the next handler, and returns its own handler.
This way, each middleware can choose whether to handle all calls,
or just some of them - while passing on the rest to "next".

This makes our API more flexible and our tests less awkward.
Most importantly, it enables #93, as a coreutils ExecHandler by design
will only be able to handle some coreutil commands and nothing else.

For #93.
@mvdan
mvdan force-pushed the handler-middleware branch from 5951b19 to e7faa65 Compare January 22, 2023 15:35
@mvdan

mvdan commented Jan 22, 2023

Copy link
Copy Markdown
Owner Author

Thanks all for the reviews!

@mvdan
mvdan merged commit 27fa5db into master Jan 22, 2023
@mvdan
mvdan deleted the handler-middleware branch January 22, 2023 16:15
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants

⌂ 换网址