Right now, RulesComponent only support specifying provided context names, which are mapped from state variables. However, d7 allowed for the definition of returned variables (including info) which are then retrieved for returning like so:
public function providesVariables() {
$provides = parent::providesVariables();
if (isset($this->info['provides']) && $vars = $this->componentVariables()) {
// Determine the full variable info for the provided variables. Note that
// we only support providing variables list in the component vars.
$provides += array_intersect_key($vars, array_flip($this->info['provides']));
}
return $provides;
}
This has the advantage, that one can properly describe the returned variable. E.g., to be a node although in the configured case the returned variable is a node of type page.
But AFAIR, this had a more important cause: It dramatically simplifies integrity checks as the returned variable info can be accessed without requiring computation of the whole metadata state of a component. Considering recursive calls, this is actually the only way we can support integrity checks as we cannot recursively calculate the execution metadata.
Comments
Comment #2
fagoComment #3
klausiAre you talking about RulesComponent or RulesComponentConfig?
I think this has been fixed with #2664700: Expose Rules components as action plugin for RulesComponentConfig.
The integrity check part for Rules components used as actions will be in #2658944: Integrity check on action and condition plugins.
Comment #4
fagoI doubt this works correctly, when you look at \Drupal\rules\Engine\RulesComponent::createFromConfiguration() you see the definitions are just ignored:
I think that can be ok for executing, but for the integrity check we need to verify the configured definition matches the real/calculated one at least?