This blog post describes the rules engine and conditional rendering, which you can use to dynamically control presentation components with the Sitecore ASP.NET CMS. For more information about the rules engine and conditional rendering, see the Rules Engine Cookbook on the Sitecore Developer Network (SDN).
This is a repost of http://sitecorejohn.spaces.live.com/blog/cns!960125F1D4A59952!399.entry.
You’ve always been able to use code and configuration to control Sitecore behavior. Sitecore CMS 6.1 and later editions include a rules engine, allowing you to control Sitecore behavior through the browser-based user interface.
The Sitecore rules engine supports the Online Marketing Suite (OMS), but also provides features such as conditional rendering. Conditional rendering allows you to define actions to invoke to control properties of each rendering dynamically bound to the page. You can use the rules engine to define other types of rules through the user interface, such as to control insert options, or to invoke specific operations after events on specific items, such as save or delete .
The rules engine involves three primary concepts: conditions, actions, and rules. Like most concepts in Sitecore, each of these involves a definition item containing metadata.
A condition definition item references a .NET class that contains a condition to evaluate, such as to determine whether an item is associated with a specific data template. Conditions define parameters, such as to allow the user to specify the data template. Sitecore provides a number of default conditions that you can use, such as checking whether an item is on the descendant-or-self axis of another item, or whether a specific field of an item contains a specific value. Of course you can implement custom conditions.
An action definition item references a .NET class that contains an action to implement, such as to set the data source of a rendering. Actions define parameters, such as to allow the user to select the that data source. Sitecore provides a number of actions that you can use, such as hiding a rendering or adding a template to insert options. Of course you can easily implement custom actions.
A rule definition item brings together some number of rules and actions, such as if the context item is on the ancestor-or-self axis of another item, then do not invoke a rendering. You have to define rules before you can use them. You can enter multiple conditions in a rule definition item (separated by “and” or “or”), , and you can select multiple actions to invoke when those conditions evaluate to True.
The rules engine interface looks a lot like the Microsoft Outlook wizard for creating a rule, such as to move messages matching some criteria from one folder to another. You choose the conditions to evaluate and the actions that you want to invoke, and then enter parameters for both.
You can see how Sitecore uses the rules engine internally by investigating the Rule field (a new data template field type in Sitecore CMS 6.1) in the Data section of the rule definition items beneath the /Sitecore/System/Settings/Rules item. For example, the /Sitecore/System/Settings/Rules/Insert Options/Rules/Conditional Renderings Conditions item defines that, when determining effective insert options for an item, if the selected item is a child of the /Sitecore/System/Settings/Rules/Conditional Renderings/Conditions item and is associated with the Common/Folder data template, then effective insert options should include the System/Rules/Condition data template:
In the first field of this user interface, you click conditions to add to the list of conditions to evaluate to determine whether to invoke the action(s). In the second field, you can select actions to invoke if those conditions evaluate to True. In the third field, clicking on any instance of the word “where” reverses the condition to “except where” – Sitecore applies the action when the condition is not true instead of when the condition is true. Clicking on the word “Conditions” allows you to select a parent item other than the /Sitecore/System/Settings/Rules/Insert Options/Rules/Conditional Renderings Conditions item (parameter of the condition and the action). Clicking on Folder or Condition allows you to select a data template other than Common/Folder or System/Rules/Condition (a parameter of the condition).
Imagine a site in that consists of the home item (/sitecore/content/home) and its two children named A and B. All three of these items are currently associated with a single data template, and all use the layout details defined in the standard values of that data template. For the B item and all of its descendants, you don’t want to activate a rendering specified in layout details of the standard values of the data template.
You could hard-code this logic in the rendering, or create a new data template inheriting from the existing data template, override standard values in the new data template, and change the data template associated with all of the items in the B branch to this new template. Or you could use conditional rendering features of the rules engine.
To use the rules engine for this purpose, insert a conditional rendering rule definition item, and then edit the rule. The rule is blank by default:
The example rule applies to the B item and its descendants, so click “where item is a subitem of a specific item” condition to add that condition to the rule:
You could click the word “where” to reverse the condition to “except where”. The user interface displays the word “specific” is red to indicate that you need to enter a parameter value. Click the word “specific” to select an item to define that parameter (the B item):
The UI refreshes to show that the parameter definition. Now select the “hide rendering” rule to invoke that rule when the condition is true:
Actions can have parameters too, but this one doesn’t. This rule says that, before invoking any rendering associated with this conditional rendering rule, if the context item is B or a descendant of B, then don’t invoke that rendering.
To apply the conditional rendering rule to all items associated with the data template, in the standard values for the data template, in layout details, in control properties for the rendering, select the conditional rendering rule:
You can also configure global conditional rendering rules, that apply to all renderings, but too many of these could get expensive. The default global conditional rendering rule applies multivariate tests if multivariate tests are enabled, applying multivariate tests to all renderings for which the user has chosen to apply a multivariate tests. Multivariate tests basically vary the data source of the rendering using a .NET class to implement some randomization or other data source management strategy, which is really a form of conditional rendering.
@Lello: It depends on what you mean by scripting. You could think of any code as defining rules, but the rules engine specifically separates conditions and actions, using rules to bring them together. Technically, an action can invoke a script - if the condition defined in a rule evaluates to true, the rules engine can fire an action that invokes a script.
See also: sitecoresnippets.blogspot.com/.../wurfl-based-mobile-detection-solution.html sitecoresnippets.blogspot.com/.../mobile-device-detector-performance.html
It would help to know that by default, conditional rendering rules are not defined in the same area as the conditions and actions, as they are with other rules engine-related items. They are located at /sitecore/system/marketing center/personalization/Rules.
BS: the rules will work in the pzn location, but the standard location, according to the Rules Engine Cookbook, is /sitecore/system/Settings/Rules/Conditional Renderings/Global Rules. fwiw, we're on v6.5.
Page Editor: Automatically assign location in item tree for components added to the layout Creating new pages takes too much time because system does not automatically take over information where to store the item in the item tree. Example: A new rich text in one grid should be automatically sorted into the grid the component belongs to Expected Result: All newly created items shall automatically be stored as sub-items of their parent item, without dialogue. Example: A new rich text in one grid component should be automatically sorted hierarchically as sub-item of the grid item: Solution Idea: “Command Templates” might be used to skip the “Create data source” dialogue and automatically store newly created items. Can you please help me on this? I took reference of sdn.sitecore.net/.../datadefinitioncookbook-a4.pdf (chapter 4) but i am not able to put logic for insert rule.
@Natasha: I believe that a command template would be the way to go if the item never moves after its creation. I would envision a wizard that prompts them to select which type of item to create, where to create it, and what to name it. If the item may need to move based on metadata that the user could update after creating the item, then something more like marketplace.sitecore.net/.../News_mover.aspx may be more appropriate. I would like to see it refactored to use the rules engine.
Hi John, Sitecore personalisation is not working when I personalise the component using the personalise button on the right side of the components. But the same thing works when I check the condition from the Personalisation section which we get when we "edit" the control. Let me know if you need any screenshot. Appreciate your help.
@Tora: I wish I could help but have not heard of anything like this. I think you would be better served by http://support.sitecore.net. At the very least, you need to provide the Sitecore version number, configuration, and potentially log files. Screen shots would help as well.