Experience Sitecore !

I was playing with SXA and wanted to have a custom element within a rendering variant that identifies current control presents on a page, otherwise it is being invisible. Looking for such a rule I suddenly realised it is not there, so had to create my custom one. I am sharing it just in case it might be useful to someone looking for a similar solution.

So, as per Rules Engine Cookbook, you create a tag, custom condition and relevant element for it:

The code is simple.

public class IsExperienceEditorEditing<T> : StringOperatorCondition<T> where T : RuleContext
{
    public int Value { get; set; }
    protected override bool Execute(T ruleContext)
    {
        return Sitecore.Context.PageMode.IsExperienceEditorEditing;
    }
}

Also, working with SXA aligned with Helix principles, it would make sense to create a foundation module for custom rules, drop the above class inside as well as serialization for newly created tag and elements:

<configuration xmlns:patch="http://www.sitecore.net/xmlconfig/" xmlns:role="http://www.sitecore.net/xmlconfig/role/" xmlns:unicorn="http://www.sitecore.net/xmlconfig/unicorn/">
  <sitecore unicorn:require="On">
    <unicorn>
      <configurations>
        <configuration name="Foundation.Rules" description="Foundation Rules" extends="Helix.Foundation">
          <predicate type="Unicorn.Predicates.SerializationPresetPredicate, Unicorn" singleInstance="true">
            <include name="$(layer).$(module).Tags" database="master" path="/sitecore/system/Settings/Rules/Definitions/Tags/Experience Editor" />
            <include name="$(layer).$(module).Elements" database="master" path="/sitecore/system/Settings/Rules/Definitions/Elements/Experience Editor" />
          </predicate>
        </configuration>
      </configurations>
    </unicorn>
  </sitecore>
</configuration>

I working on a rendering variant in order to implement a component similar to the one below:

The component should display a heading title, followed by a list of promo blocks leading to the other pages. What is important here, is that different page types can be assigned into given component, of course they all do implement _Promotable interface template that has fields allowing them being promoted through this component. So far, so good.

But notice, each promo block has its type in left top corner painted into appropriate color. The values of it (article, topic, blog) are actually types of the pages, they do not present in generic _Promotable interface template, but do match template names, so why not to expose template names for these fields?

The easiest way of doing that is to create a label for each of the page type and assign it corresponding CSS class to display in appropriate color. 

Then we may use built in Rules Engine in order to create a rules for each of these page type labels to be shown only if the item template matches given page type. Here's how it looks in Content Editor:

Also, there is another way of achieving the same goat - using NVelocity templates: create a Variant Template field and expose current template name:

That will also work since type badge matches name of page template in our case, but will need some extra work to wire up CSS class, that should derive from template name in this or that way.

Once I was asked to personalize Sitecore component depending on custom URL query string parameter, to identify users coming by a promo campaign in order to display them slightly modified component reflecting campaign presentation. Easy, I thought, but in next couple minutes struggled to find that condition in Rules Engine. It is not in Sitecore, what a surprise!..

So, let's go through and see what conditions are in Sitecore and how you can create any custom condition you would ever imagine.

First of all, all stuff for Rules Engine is specified as Sitecore items underneath /sitecore/system/Settings/Rules folder. So let's create an item named Query String Value Presents of /sitecore/templates/System/Rules/Condition template within /sitecore/system/Settings/Rules/Conditional Renderings/Conditions/URL Query String Conditions folder. There are just two important fields we are going to set. Type field, as it is very common to Sitecore, specifies fully qualified class and assembly names, where business logic is implemented. Another, Text field, is more interesting on that stage - it shows wordings that would be presented to user when using his condition with Rules Engine. Here is what we set there:

Where the User [QueryStringName,,,QueryString Name] has a value that [operatorid,StringOperator,,compares to] [QueryStringValue,,,QueryString Value].

Pay attention to parameters in square brackets - they would be replaced by Rules Enging to selectors.

Now let's look at the code. Fom the item we ahave referenced the class.

public class QueryStringCondition<T> : StringOperatorCondition<T> where T : RuleContext

All derived condition classes should have same definition and derive from base StringOperatorCondition class. As the absolute minimal, we are to override just one Execute(T ruleContext) method. Additionally we must create public string properties named exactly the same as in parameters above from Text field from condition definition item in Sitecore.

public string QueryStringName { get; set; }
public string QueryStringValue { get; set; }
protected override bool Execute(T ruleContext)
{
    // process QueryStringName and QueryStringValue properties here
    // return true if personlization parameters falls within the condition 
}

QueryStringName and QueryStringValue would be auto-populated by Rules Engine.

With our next example we are trying to display an additional promo component when user access our website by URL with sourceId=campaign as parameters.

Full implementation of QueryStringCondition<T> class can be found on GitHub by this link.