This recipe explains the benefits of using Components by creating a Condition that can be re-used in other rule configurations.
In this scenario, we want to perform some action when a node is being commented on. But we only want to execute the action if the node was not created by the super admin (that is, user 1) and the node is either an article, or has an image field (field_image).
Go to Configuration | Workflow | Rules | Components.
Add a new component and set the plugin to Condition set (AND).
Enter a name for the component and add a parameter Entity | Node.
Add a Condition, Data comparison, set the value to the author of the node, set OPERATOR to equals, enter 1 in the Data value field and tick Negate.
Add an OR group by clicking on Add or, as shown in the following screenshot:
Add a Condition, Node | Content is of type and set it to Article.
Add a Condition, Entity | Entity has field, set Entity to node, and select the field, field_image, as shown in the following screenshot:
Organize the Conditions so that the last two Conditions are in the OR group we created before.
Create a new rule configuration and set the Event to Comment | After saving a new comment.
Add a new Condition and select the component that we created. An example is shown in the following screenshot:
Select comment:node as the parameter.
Add a new Action, System | Show a message on the site and configure the message.
Components require parameters to be specified, that will be used as placeholders for the objects we want to execute a rule configuration on. Depending on what our goal is, we can select from the core Rules data types, entities, or lists.
In this example, we've added a Node parameter to the component, because we wanted to see who is the node's author, if it's an article or if it has an image field. Then in our Condition, we've provided the actual object on which we've evaluated the Condition. If you're familiar with programming, then you'll see that components are just like functions; they expect parameters and can be re-used in other scenarios.
The main benefit of using Rules components is that we can re-use complex Conditions, Actions, and other rule configurations. That means that we don't have to configure the same settings over and over again. Instead we can create components and use them in our rule configurations.
Other benefits also include exportability: components can be exported individually, which is a very useful addition when using configuration management, such as Features.
Components can also be executed on the UI, which is very useful for debugging and can also save a lot of development time.
Apart from Condition sets, there are a few other component types we can use. They are as follows:
Action set
As the name suggests, this is a set of Actions, executed one after the other. It can be useful when we have a certain chain of Actions that we want to execute in various scenarios.
Rule
We can also create a rule configuration as a component to be used in other rule configurations. Think about a scenario when you want to perform an action on a list of node references (which would require a looped Action) but only if those nodes were created before 2012. While it is not possible to create a Condition within an Action, we can create a
Rulecomponent so we can add a Condition and an Action within the component itself and then use it as the Action of the other rule configuration.Rule set
Rule sets are a set of Rules, executed one after the other. It can be useful when we want to execute a chain of Rules when an event occurs.
Condition sets require parameters which are input data for the component. These are the variables that need to be specified so that the Condition can evaluate to FALSE or TRUE.
Action sets, Rules, and Rule sets can provide variables. That means they can return data after the action is executed.
