dotnet / dotnet/command-line-api
[Discussion] Upcoming changes regarding middlewares: my use case
- Dominant language
- C#
- Stars
- 3.7k
- Forks
- 428
- PR merge metrics
- No merged PRs in 30d
Description
Hey, I've just seen, that you want to hear from us, how we use the middleware pipeline (see #1882)... Well I do, and it is quite messy and I really do not like it this way, but it seems to work!?
I have written a domain-related ["plugin" that is owning the command-line infrastructure](https://github.com/vernuntii/vernuntii/blob/2fadf4eb600d46820e9ee8f4f2e7d60a6f70f9f3/src/Vernuntii.Runner/Plugins/CommandLinePlugin.cs). It allows having a root command handler and symbols (sub-commands, options and arguments) set from another domain-related plugin.
The procedure is the following:
1. [I first setup the CommandLineBuilder](https://github.com/vernuntii/vernuntii/blob/2fadf4eb600d46820e9ee8f4f2e7d60a6f70f9f3/src/Vernuntii.Runner/Plugins/CommandLinePlugin.cs#L76) which also inserts a middleware, before any other, to [capture an occuring exception](https://github.com/vernuntii/vernuntii/blob/2fadf4eb600d46820e9ee8f4f2e7d60a6f70f9f3/src/Vernuntii.Runner/Plugins/CommandLinePlugin.cs#L89) which may originate from a command handler in upcoming middlewares.
3. Then I insert [another middleware](https://github.com/vernuntii/vernuntii/blob/2fadf4eb600d46820e9ee8f4f2e7d60a6f70f9f3/src/Vernuntii.Runner/Plugins/CommandLinePlugin.cs#L165) that is placed after "--help"- and "parse"-middleware. The middleware has the job to [get access to `((InvocationContext)context).ParseResult`](https://github.com/vernuntii/vernuntii/blob/2fadf4eb600d46820e9ee8f4f2e7d60a6f70f9f3/src/Vernuntii.Runner/Plugins/CommandLinePlugin.cs#L168) when this [middleware was called the first time](https://github.com/vernuntii/vernuntii/blob/2fadf4eb600d46820e9ee8f4f2e7d60a6f70f9f3/src/Vernuntii.Runner/Plugins/CommandLinePlugin.cs#L171).
4. I [build the parser](https://github.com/vernuntii/vernuntii/blob/2fadf4eb600d46820e9ee8f4f2e7d60a6f70f9f3/src/Vernuntii.Runner/Plugins/CommandLinePlugin.cs#L177) from the `CommandLineBuilder` and invoke `parser.InvokeAsync` the first time, the so called "parser routine". I now have access to `(ParseResult)parseResult`.
5. Then after every plugin could evaluate the `(ParseResult)parseResult`, I invoke `(ParseResult)parseResult.InvokeAsync()`. The middleware gets called another time, but now [we let the middleware run through](https://github.com/vernuntii/vernuntii/blob/2fadf4eb600d46820e9ee8f4f2e7d60a6f70f9f3/src/Vernuntii.Runner/Plugins/CommandLinePlugin.cs#L173) and the command handler gets invoked the first time. This is the so called "command handler routine".
What makes this procedure super cool is having the "parser routine" and the "command handler routine" splitted. It would be nice, if if this could be somehow preserved and taken into account when replacing the middleware-API.
To be honest, the way I grab the parser result seems a little bit odd. What also irritated me was, that the parser result owned implictly the parser/middleware pipeline. I think a redesign seems here the right approach and I am looking forward to engage in constructive criticism if desired.
Contributor guide
Assessment
This issue has not been assessed yet.