eclipsegc / plugins Goto Github PK

Currently \EclipseGc\Plugin\Traits\PluginDiscoveryTrait::$keyedDefinitions exists and probably should not. Rather this should be refactored out in favor of just a $definitions property on the trait. Currently one is keyed by plugin id and the other by simple numeric array keys.

This could end up touching on the \Iterator implementation of PluginDiscoveryInterface in favor of something like Symfony's "Bag" classes instead of a native array in the Discovery object and making discovery iterate-able.

In Drupal 8, we provided a pluggable factory solution for plugins. This was good in theory, but in practice, too often, a plugin had to be aware of its own needs from a dependency injection perspective. This meant a lot of static factory methods on plugins with hard-coded dependencies on services in a container. This is impossible to override without subclassing the entire plugin which isn't particularly usable or desirable.

Instead of committing to a factory that must work for ALL plugins of a particular type, I propose the new PluginDefinitionInterface be expanded to include documentation of __construct() requirements. This passes the "buck" to PluginDefinitionInterface when it's instantiated to include the appropriate things like a service container (when necessary), but I find that preferable to forcing that knowledge onto the plugin classes themselves.

Configurable plugins should be part of the basic offering of Plugins. In Drupal 8 we did this via arrays for configuration, but this means that the plugin was in charge of things like validating configuration, serializing itself for storage, etc, etc.

We should write this such that a given plugin expects a given configuration object (which extends a common interface). This configuration object should be capable of validating its values and serializing its values.

The existing discovery object is really just a dictionary of definitions. We need to introduce real discovery and refactor as appropriate.