RFC: Widgets / Plugins / Middleware / Argument Injector thingie #4
Conversation
Pull Request Test Coverage Report for Build 8638167516Details
💛 - Coveralls |
|
|
||
| use Attribute; | ||
|
|
||
| #[Attribute(Attribute::TARGET_CLASS)] |
There was a problem hiding this comment.
These globals should probably never be used for anything other than --help, --verbosity --silent etc.
| @@ -4,13 +4,18 @@ | |||
|
|
|||
| namespace Tempest\Console; | |||
|
|
|||
| use ReflectionClass; | |||
There was a problem hiding this comment.
this obviously needs a refactor before it gets merged =)
| ) { | ||
| } | ||
|
|
||
| public static function fromParameter(ReflectionParameter $parameter): ConsoleArgumentDefinition | ||
| public static function fromParameter(ReflectionParameter $parameter, bool $asPositional = true): ConsoleArgumentDefinition |
There was a problem hiding this comment.
Injected arguments always have to be named arguments to avoid collisions
|
@brendt do we want to salvage anything out of this or should I close it? I think you already handled some of the global options in a different way on stream but can't remember the deets |
|
I think there's still room for improvement to what I did, but maybe it's best to take more incremental steps. In truth, I haven't been able to look at this PR in depth. Maybe keep it open for now, I'll definitely go through it and might cherry-pick some stuff straight into main when #21 is merged |
|
So, I really like the widget approach, but I feel like we need to get middleware straight first. I'll take care of that, and then we can revisit this idea |
Good morning!
I've been tinkering with the idea from the initial PR a bit more and came up with this initial concept.
Note: I haven't spent much time on this, let's treat this as a draft of functionality that we want to have.
So, as the title suggests - not sure about name, I'll just stick with widgets for now which is probably the worst name but 🤷
The goal of widgets is to create a way to inject additional arguments into the console.
This can be useful for example when our command requires an API key, that could be automatically injected if not provided, or it'd use the passed one.
Widgets can be defined both globally (maybe it'd be nice to add "namespace" param for the
#[GlobalConsoleWidget]so all commands within i.edb:namespace would be affected) and locally in command definition.I think the biggest place for discussion is what contract the invoke method should have and what should be modifiable - but this would require validation to run twice: