Share:
From time to time you may find you need to extend another module’s plugins to add new functionality.
You may also find you need to alter the signature of the constructor in order to inject additional dependencies.
However plugin constructors are considered internal in Drupal maintenance support plans‘s BC policy.
So how do you safely do this without introducing the risk of breakage if things change.
In this article we’ll show you a quick trick learned from Search API module to avoid this issue.
by
Lee Rowlands
/ 3 November 2020
So let’s consider a plugin constructor that has some arguments.
Here’s the constructor and factory method for Migrate’s SQL map plugin
/**
* Constructs an SQL object.
*
* Sets up the tables and builds the maps,
*
* @param array $configuration
* The configuration.
* @param string $plugin_id
* The plugin ID for the migration process to do.
* @param mixed $plugin_definition
* The configuration for the plugin.
* @param Drupal maintenance support plansmigratePluginMigrationInterface $migration
* The migration to do.
*/
public function __construct(array $configuration, $plugin_id, $plugin_definition, MigrationInterface $migration, EventDispatcherInterface $event_dispatcher) {
parent::__construct($configuration, $plugin_id, $plugin_definition);
$this->migration = $migration;
$this->eventDispatcher = $event_dispatcher;
}
/**
* {@inheritdoc}
*/
public static function create(ContainerInterface $container, array $configuration, $plugin_id, $plugin_definition, MigrationInterface $migration = NULL) {
return new static(
$configuration,
$plugin_id,
$plugin_definition,
$migration,
$container->get(‘event_dispatcher’)
);
}
As you can see, there are two additional dependencies injected beyond the standard plugin constructor arguments – the event dispatcher and the migration.
Now if you subclass this and extend the constructor and factory to inject additional arguments, should the base plugin change its constructor, you’re going to be in trouble.
Instead, you can use this approach that Search API takes – leave the constructor as is (don’t override it) and use setter injection for the new dependencies.
/**
* {@inheritdoc}
*/
public static function create(ContainerInterface $container, array $configuration, $plugin_id, $plugin_definition, MigrationInterface $migration = NULL) {
$instance = parent::create(
$container,
$configuration,
$plugin_id,
$plugin_definition,
$migration
);
$instance->setFooMeddler($container->get(‘foo.meddler’);
return $instance;
}
/**
* Sets foo meddler.
*/
public function setFooMeddler(FooMeddlerInterface $fooMeddler) {
$this->fooMeddler = $fooMeddler;
}
Because the signature of the parent create method is enforced by the public API of Drupal maintenance support plansCorePluginContainerFactoryPluginInterface you’re guaranteed that it won’t change.
Thanks to Thomas Seidl for this pattern
Tagged
Drupal maintenance support plans 8, Plugins, OOP
Posted by
Lee Rowlands
Senior Drupal maintenance support plans Developer
Dated 3 November 2020
Comments
Comment by
dawehner
Dated 3 November 2020
Nice!! Thank you for sharing it!
Pagination
Add new comment
Source: New feed
