Spin-off from #2293773: Field allowed values use dots in key names - not allowed in config.
Extracting the "class" for a plugin ID has only been envisionned as part of a "create a plugin instance" - and thus been placed in DefaultFactory::getPluginClass().
However some plugin types (including field types) involve static methods on their plugin classs.
Thus, there are various places that need to extract a plugin class for a plugin ID, without any intention of instanciating the plugin.
You can do that directly (getPluginDefinition(), grab the 'class'), but a lot of places do that by hardcoding a call to DefaultFactory::getPluginClass(), which feels really hackish.
"Get the class for a plugin ID" is more related to discovery generally than to just instanciation and factories.
--> Add getPluginClass() to DiscoveryInterface ?
or maybe just to DefaultPluginManager, as a "nice helper to have" ?
(it's obviously a "nice helper to have", given the number of places that call it on an arbitrary factory class they have otherwise no business with)
Comments
Comment #1
XanoSince the class can easily be retrieved from a plugin's definition, even without instantiating the class, I am wondering what value a public method like this would add. The additional logic in
DefaultFactory::getPluginClass()
is really just validation, which should perhaps actually be part of the discovery phase, but it's not something you'd need outside the plugin system.Comment #2
Xano#2458789: Introduce PluginDefinitionInterface adds an API for this.
Comment #3
Xano#2458789: Introduce PluginDefinitionInterface now passes all tests and is ready for manual review. It allows us to get a plugin's class by calling
DiscoveryInterface::getDefinition()->getClass()
.Comment #4
XanoPlugin classes are contained by plugin definitions and should be extracted from those.
\Drupal\Component\Plugin\Definition\PluginDefinitionInterface
provides for this. When dealing with array-based plugin definitions, either convert them to objects, or use the Plugin module.