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

Xano’s picture

Since 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.

Xano’s picture

Xano’s picture

#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().

Xano’s picture

Status: Active » Closed (works as designed)

Plugin 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.