Follow up from #1743686: Condition Plugin System. getConfig() and setConfig() are useful for all plugins where configuration needs to be gotten or set after plugin instantiation. getConfigDefinition() and getConfigDefinitions() are useful for all plugins that want to support configuration introspection UIs and APIs (like Rules does). None of this is specific to "executable" plugins.
This is also a good issue to further discuss the difference between runtime swappable configuration and context, since these methods currently overlap quite a bit with the various context related ones. In Rules, there is no difference. But in Blocks, there is. There's a little discussion of this in the original issue, but I'm not up to speed enough on it to summarize that here. Someone who is: please do.
Comments
Comment #1
effulgentsia commentedIt's possible this issue also overlaps a bit with #1764380: Merge PluginSettingsInterface into ConfigurableInterface?
Comment #2
effulgentsia commentedComment #3
fagoEclipseGc and I discussed this quite a bit on skype. I'm actually not sure what the exact reasons for separating those are, but EclipseGc generally aimed for a hard separation between those too and can surely explain better why he wants to do that. As not having this hard-separation is what is the heart of what makes Rules so flexible by allowing the configuration of actions/condition parameters either from context or configuration, we agreed upon providing sufficient metadata for configuration also such that we can move on and Rules can continue to do so.
I'd be interested to hear on what the difference for blocks is, as I'm not into that.
As I see it, to the plugin it should not have to matter. It generally is some data the plugin needs in order to function on run-time, the plugin should not have to care whether the data is retrieved on run-time or pre-configured. Thus, I see it as a "parameter" to a plugin that could be provided either from context or via configuration. For example it allows you to keep your configuration else-where, e.g. in og-group entities and pass it on to Rules actions that then behave according to the group settings - think of e-mail texts for an example.
Still, we need to separate between parameters that are provided via context or configuration by default. Rules does that on a per data-type basis and allows to overwrite this default per parameter + allows you to switch context/configuration input odes per ajax. Switching is definitely more than we need in core, thus I'll look into providing that via Rules - ideally to all action/condition forms providing sufficient metadata. For cases where the parameter value is necessary on configuration time (e.g. a create an entity action needs to know the entity type) Rule allows to restrict input to configuration only.
For core having a sane default per data-type would suffice imho. With the current system we basically have a default per parameter, but yes I'm not sure we need to have the hard-distinction between configuration and context parameters baked into the API. Imho the APIs would get better without the distinction as you could configure all parameters consistently before executing:
vs.
Comment #17
smustgrave commentedThank you for creating this issue to improve Drupal.
We are working to decide if this task is still relevant to a currently supported version of Drupal. There hasn't been any discussion here for 8+ years which suggests that this has either been implemented or is no longer relevant. Your thoughts on this will allow a decision to be made.
Since we need more information to move forward with this issue, the status is now Postponed (maintainer needs more info). If we don't receive additional information to help with the issue, it may be closed after three months.
Thanks!
Comment #18
smustgrave commented3 months has past so closing out, but don't worry if still a valid task this can be re-opened by anyone.
Thanks!