Sed ut perspiciatis unde omnis iste natus error sit voluptatem accusantium doloremque laudantium, totam rem aperiam, eaque ipsa quae ab illo inventore veritatis et quasi architecto beatae vitae dicta sunt explicabo. Nemo enim ipsam voluptatem quia voluptas sit aspernatur aut odit aut fugit, sed quia consequuntur magni dolores eos qui ratione voluptatem sequi nesciunt. Neque porro quisquam est, qui dolorem ipsum quia dolor sit amet, consectetur, adipisci velit, sed quia non numquam eius modi tempora incidunt ut labore et dolore magnam aliquam quaerat voluptatem. Ut enim ad minima veniam, quis nostrum exercitationem ullam corporis suscipit laboriosam, nisi ut aliquid ex ea commodi consequatur? Quis autem vel eum iure reprehenderit qui in ea voluptate velit esse quam nihil molestiae consequatur, vel illum qui dolorem eum fugiat quo voluptas nulla pariatur?
Experience Sitecore! | All posts tagged 'Rules-Engine'

Experience Sitecore!

Martin Miles on Sitecore

Rule missing OOB in Sitecore, where the Experience Editor is in editing mode

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>
So now I can have an element withing rendering variant that is shown only when in editing mode:

Hope you find this helpful!

Quick tip: using rules engine for SXA rendering variants

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:


Note! If you cannot access your condition through SXA built-in Rule Engine, you need to assign tag to Conditional Renderings tags (/sitecore/system/Settings/Rules/Conditional Renderings):


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.

Sitecore Personalization based on URL query string parameters

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.

Hope you find this helpful!