You’ve always been able to use code and configuration to control Sitecore behavior. Sitecore CMS 6.1, scheduled for release at the end of this June, 2009, includes 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.

With the release of Sitecore CMS 6.1 and OMS 1, Sitecore will release documentation providing providing further details about the rules engine and conditional rendering.

Update 30.June.2009: Sitecore today published the Rules Engine Cookbook, which also covers conditional rendering.