drush-ops
WIP: Convert field commands to Symfony Console commands
@weitzman any chance we can keep the input(), 'output()andio()methods on command classes? It would make it a lot easier to convert commands. Also, having to create aDrushStyleinstance every time you want to output something feels overly verbose and like a step backwards. I'm convertingFieldCreateCommands` and I just end up having to pass input and output objects all over the place, adding a lot of noise.
In the simplest form it could be a trait with the before mentioned methods and properties storing the objects, and a setIo(InputInterface $input, OutputInterface $output) that should be called at the start of the execute() method, but if that last part could be abstracted away, even better.
@weitzman I just read that custom events are deprecated, seemingly without full alternative. What am I supposed to convert this kind of code to?
// Command files may set additional options as desired.
$handlers = $this->getCustomEventHandlers('field-create-set-options');
foreach ($handlers as $handler) {
$handler($input);
}
That would be nice, but we are trying not to extend \Symfony\Component\Console\Command\Command. Once we do that, our commands rely a bit more on Drush-isms and are harder to reuse in other CLIs like a future one by Drupal core. I hear you that it feels like a step backward. Hopefully that step is for a good cause in the end.
You should emit events using event_dispatcher from the container. Then you write listeners to react to those events. See https://github.com/drush-ops/drush/blob/3d4bf9c74dcf94041dbcd82882ead6cdacc30245/src/Commands/sql/sanitize/SanitizeCommand.php#L55-L57. Also there is an example in CacheClearCommand
I have passed around $input->getOptions() in places where I used to pass around $options. If you dont want to pass around a DrushStyle and don't want to keep creating it, you could store it on a property on the command class. You could do that in a trait like you say. Start the trait just for the field commands and then we can consider making it more available.
These io methods wouldn't have to exist in a base class, we could just provide a trait right? An optional IoTrait for big command classes that do a lot of input/output spread across multiple methods. Or I could add this straight to FieldCreateCommands, but I feel like it could be useful in more places.
After some more thought, I like the IoTrait idea. Feel free to make one that all commands can use. $this->setIO() should return the DrushStyle object in the fluent style so that the author can immediately start asking questions.
Conversion is done, tests are passing! Also creating MR's here:
- https://www.drupal.org/project/entity_reference_revisions/issues/3364421
- https://www.drupal.org/project/entity_bundle_scaffold/issues/3563442